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ABSTRACT 


A  study  -4-s-  made  to  integrate  finite  element-based-optimal 
structural  design  methods  and  computer-science  methods  into  a  computer- 
based  system  containing  a  database,  a  program  library  and  man-machine 
communication  link.  Emphasis  is  placed  upon  database  management 
concepts  for  structural  design.  Important  components  required  to  build 
a  computer-aided  structural  design  system  are  described.  A  number  of 
database  management  concepts  --  hierarchical,  network  and  relational 
data  models,  conceptual,  internal  and  external  view  of  data 
organization,  normalization  of  data,  and  global  and  local  database  are 
discussed  with  reference  to  structural  design  data.  A  methodology  to 
design  a  database  is  proposed.  Three  levels  of  data  organization- 
conceptual,  internal  and  external  are  suggested.  A  methodology  to 
construct  a  numerical  data  model  is  described.  This  model  supports  data 
of  various  types  of  large  matrices  such  as  banded,  skyline  and 
hypermatri ces .  Requirements  of  database  management  system  and 
components  needed  to  develop  it  are  discussed.  Language  requirements  to 
enable  good  communication  link  between  designer  and  computer  are 
formulated.  A  database  management  system  -  MIDAS  is  implemented  for  use 
in  structural  design  applications.  MIDAS  supports  both  relational  and 
numerical  data  models.  It  can  be  used  either  through  application 
program  calls  or  interactively.  A  database  for  structural  design 


optimization  is  designed  using  the  proposed  methodology.  A  computer 
program  for  finite  element  analysis  and  structural  design  optimization 
is  developed.  The  program  uses  database  and  the  database  management 
system  MIDAS.  The  program  is  based  on  hypermatrix  approach  for  assembly 
and  solution  of  large  matrix  equations.  Several  example  problems  are 
solved  using  the  program.  An  evaluation  of  data  model,  database  and 
database  management  system  in  computer-aided  structural  design 
optimization  environment  is  made.  The  performance  of  MIDAS  in  equation 
solving  environment  is  determined  using  skyline  and  hypermatrix 
approach.  Finally,  it  is  concluded  that  with  the  proposed  data  models, 
database  design  methodology,  and  the  advanced  database  management 
system,  computer-aided  design  optimization  of  complex  structural  systems 


can  be  attempted. 
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CHAPTER  1 
INTRODUCTION 


1.1  Introductory  Remarks 

Advances  in  computer  technology  have  brought  about  profound  changes 
in  the  way  engineering  analysis  and  design  are  performed.  In  structural 
analysis  computer  has  become  a  vital  adjunct  to  theory.  Several  general 
purpose  computer  programs  having  a  wide  range  of  capabilities  are 
currently  in  use  for  finite  element  analysis  of  structures.  In  the 
structural  design  field,  computer  programs  are  being  developed  for 
optimal  design.  But,  they  are  in  the  early  stage  of  development  and  are 
facing  a  number  of  problems  in  design  of  practical  structures.  Problems 
arise  due  to  iterative  nature  of  optimal  design  algorithms  and  need  for 
reanalysis  of  the  structure  in  each  iteration.  Reanalysis  of  a 
structure  using  existing  finite  element  programs  are  difficult  because 
they  are  not  flexible  to  use  modified  data  generated  at  various  design 
stages.  Moreover,  designer  needs  control  over  the  program  and  data  in 
selecting  appropriate  algorithms  and  data  to  obtain  optimum  solution. 
Thus,  there  exists  a  wide  gap  between  structural  analysis  and  design 
capabilities.  To  bridge  this  wide  gap,  it  is  necessary  to  establish 
approaches  through  integration  of  computers  in  the  design  environment. 


The  term  computer-aided  design  has  evolved  over  years  which  provide  a 
good  basis  for  such  an  integration. 
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Computer-aided  design  (CAD)  means  integration  of  engineering 
methods  and  computer-science  in  a  computer-based  system,  using  a 
database,  a  program  library  and  a  man-machine  communication  link.  The 
term  computer-aided  design  optimization  (CAD-OPT)  is  derived  from  the 
above  definition  to  cover  analysis  and  design  optimization  methods.  In 
this  study  a  new  concept  is  presented  for  integrating  structural 
analysis  and  design  optimizat  on  methodology  into  a  computer-based 
system  which  encompases  this  meaning  of  CAD.  Emphasis  is  placed  upon 
database  management  concepts  for  finite  element  analysis  and  structural 
design  optimization. 


Knowledge  about  the  historical  background  provides  a  better 
understanding  of  the  state-of-the-art.  Going  back  to  1960,  Integrated 
Civil  Engineering  Systems  (ICES)  development  was  an  important  milestone 
in  the  use  of  computers  in  solving  civil  engineering  problems.  It  was 
based  on  the  idea  of  integrating  computers  in  the  problem  solving 
environment  to  provide  faster,  more  accurate  and  complete  analysis  and 
design  capability  to  engineers.  During  the  same  period,  theory  of  the 
finite  element  method  began  to  evolve  and  led  to  the  development  of 
several  finite  element  analysis  programs.  The  computer  programs  such  as 
NASTRAN,  STRUDL,  and  ASKA  are  well  known  and  widely  used  for  finite 
element  analysis.  Many  of  these  programs  are  qui ce  sophisticated,  large 
in  size  and  are  capable  of  analyzing  a  wide  variety  of  structural 
problems.  With  the  advances  in  computer  technology,  computers  are 
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available  at  a  lesser  cost  and  have  additional  facilities  like  graphic 
display,  and  large  disk  capacities.  Finite  element  programs  were 
designed  to  make  use  of  such  facilities  to  display  finite  element  mesh, 
store  large  amounts  of  data  on  disk  and  provide  interactive  facility  to 
users.  Programs  like  GIFTS,  ANSYS,  and  ADINA  were  developed  in  the 
seventies  to  provide  these  new  features  to  users. 

During  the  last  decade,  research  activity  in  the  area  of  structural 
design  optimization  increased.  Investigations  on  nonlinear  programming 
techniques  in  structural  optimization  became  one  of  the  major  topics  of 
research.  Several  computer  programs  were  developed  for  solving 
structural  optimization  problems.  These  include  DOCS  (Arora,  et  al  . , 
1984a),  ACCESS  (Fleury,  et  al.,  1981),  PROSSS  ( Sobi eszczanski -Sobieski  , 
et  al.,  1980)  ODYSSEY  (Bennett,  1979)  and  others  having  moderate  range 
of  capabilities  in  solving  optimization  problems.  They  use  finite 
element  method  for  analysis  of  structures.  DOCS  program  has  capability 
to  use  substructuring,  design  damaged  structures,  and  to  use  gradient- 
based  techniques  for  optimization.  PROSSS  uses  SPAR  program  for  finite 
element  analysis.  Many  of  these  programs  were  developed  to  study 
problems  of  research  interest.  Therefore,  applicability  of  the  programs 
to  general  structural  problems  is  limited.  None  of  these  programs  is 
linked  to  any  pre-  or  post-processor  making  input  to  program  and 
analysis  of  results  extremely  difficult.  Studies  are  being  made  to 
develop  good  structural  design  optimization  programs  that  are  comparable 
to  the  generality  and  capabilities  of  existing  finite  element  programs. 
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Since,  finite  element  analysis  of  structures  uses  large  amount  of 
data,  some  routines  were  incorporated  into  finite  element  packages  to 
store  data  on  secondary  storage  devices.  Data  management  using  these 
routines  was  tedious  and  applicable  only  to  one  program.  Data  generated 
by  finite  element  packages  were  almost  impossible  to  use  in  other 
programs  for  further  analysis  and  design  of  structures.  Development  of 
design  optimization  algorithms,  faced  this  problem  for  using  analysis 
data  generated  by  finite  element  packages.  Iterative  design  process 
posed  a  big  challenge  not  only  in  efficient  use  of  computer  resources, 
but  also  in  organization  of  a  large  amount  of  data  of  finite  element 
analysis  and  design  optimization  methods.  At  this  stage,  engineering 
software  designers  began  to  think  of  introducing  database  management 

concepts  into  the  software  similar  to  those  of  business  database 

management  systems.  Several  database  management  programs  were  developed 
in  the  late  seventies  and  in  the  beginning  of  the  eighties  for 

engineering  applications.  Integrated  programs  for  Aerospace  Vehicle 
Design  (IPAD)  development  is  an  important  milestone  in  engineering 
database  management.  A  database  management  system  called  RIM  (RIM, 
1982)  was  developed  under  IPAD  project.  Several  application  programs 
such  as  SPAR  (Giles  and  Haftka,  1978),  BANDIT  (band  width  minimization), 
PROSS,  ATLAS,  and  NPLOT  (graphics)  were  tied  together  with  a  common 
database  for  integrated  design  of  structural  systems  (Fishwick  and 
Blackburn,  1982).  However,  use  of  a  database  in  these  application 

programs  was  limited  to  input  and  output  only.  There  does  not  exist  a 
finite  element  program  which  directly  uses  a  generalized  database 


management  system  such  as  the  one  developed  for  IPAD  project.  Studies 
are  being  made  to  incorporate  a  database,  a  program  library  and  man- 
machine  communication  link  as  needed  for  computer-aided  structural 
design.  Emphasis  on  blending  computer-science  and  engineering 
methodology  toward  arriving  at  efficient  and  economic  design  of 
structural  systems  seems  to  be  the  goal  of  CAD  today. 

1.3  Motivation  for  Research 

In  optimal  design  of  structural  systems  we  generally  use  nonlinear 
programming  and  finite  element  techniques.  Nonlinear  programming 
techniques  require  formulation  of  design  objectives  and  constraints  of 
the  system.  They  use  large  amount  of  data  depending  on  the  size 
and  complexity  of  problem.  Organization  of  data  related  to  design 
variables,  geometry,  material,  loads,  and  intermediate  computation  data, 
generated  and  used  in  design  of  large  structural  systems  is  a  tedious 
task.  Finite  element  techniques  are  usually  adopted  to  analyze  the 
system  within  a  design  iteration.  As  such  the  finite  element  techniques 
require  huge  amount  of  computation  and  data  storage  depending  on  the 
size  of  problem  at  hand.  Further,  the  amount  of  data  handled  depends 
directly  on  the  number  of  iterations  performed  in  iterative  design 
optimization  algorithms.  Therefore,  there  is  a  need  for  data 
organization  in  optimal  design  of  structural  systems. 

In  this  regard,  i ncorporati ng  a  database  into  structural  design 
programs  looks  attractive.  Such  a  database  can  provide  data  for  both 
structural  design  optimization  and  finite  element  analysis  programs.  It 


will  enable  designers  to  choose  appropriate  data  from  the  database  and 
use  them  in  any  optimization  algorithms  to  improve  design.  Also,  data 
used  and  generated  in  one  program  can  be  made  available  for  use  in 
another  program.  Since,  most  of  the  data  for  finite  element  analysis 
and  design  optimization  are  common,  a  centralized  database  will  provide 
efficient  organization  of  computer  resources.  A  centralized  database 
allows  interaction  between  a  finite  element  program  and  an  optimization 
program  to  improve  design  iteratively.  Such  a  database  will  provide  an 
option  for  the  designer  to  interrupt  the  program  execution  and  provide 
flexibility  for  the  designer  to  change  the  design  parameters.  A  good 
database  will  enable  addition  of  new  optimization  and  other  programs 
which  use  the  common  data  without  extensive  modification  of  database  or 
existing  programs.  Also,  several  designers  can  be  allowed  to  use  a 
common  database  to  investigate  alternate  designs.  Interactive  graphics 
data  can  be  stored  in  a  database  to  provide  easy  communication  between 
computer  and  designer.  Therefore,  a  properly  designed  database, 
together  with  a  set  of  design  programs  and  communication  system,  offer  a 
considerable  aid  to  engineers  involved  in  design  optimization. 

In  view  of  the  above  observation,  we  will  investigate  design  and 
use  of  a  database  and  a  database  management  system  in  structural  design 
optimi zation . 


1.4  A  Survey  of  literature 

A  survey  of  literature  of  data  management  in  computer-aided 
structural  design  is  given  in  this  section.  The  survey  also  includes 


a  menu  of  analysis  programs  called  by  the  designer.  Later,  CAD  became 
synonymous  with  computer-aided  drafting.  However,  a  true  description  of 
CAD  is  synergistic  interplay  of  man  and  computer  (Allan  1972).  A  more 
appropriate  definition  of  CAD  is  given  by  Encarnacao  and  Schl echtendahl 
(1983):  "It  is  a  discipline  that  provides  know-how  in  computer-software 
and  hardware  in  system  analysis  and  in  engineering  methodology  for 
specifying,  designing,  implementing,  introducing,  and  using  computer 
based  systems  for  design  purpose." 

The  paper  by  Felippa  (1979)  serves  as  an  introduction  to  the 
subject  of  database  management  for  scientific  and  engineering 
appl ications .  It  highlights  the  differences  between  the  business  data 
management  and  scientific  data  management.  A  comprehensive  list  of 
terminology  relevant  to  scientific  computing  is  given  in  another  paper 
by  the  author  (Felippa,  1980).  Since,  the  terminology  used  in  business 
DBMS  is  fairly  new  to  engineers,  this  list  serves  as  a  starting  point 
for  the  newcomers.  It  is  interesting  to  know  how  scientists  actually 
use  their  data.  The  paper  by  Bell  (1982)  discusses  some  issues  about 
data  usage  and  also  gives  comparison  between  data  modelling  for 
scientific  and  business  appl ications.  In  order  to  bring  out  differences 
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between  the  use  of  database  for  business  and  engineering  applications, 
Foisseau  and  Valette  (1982)  describe  a  list  of  criteria. 

The  application  of  data  management  in  finite  element  analysis  and 
design  optimization  computation  is  fairly  new.  Even  though,  data 
management  in  these  computations  is  critically  needed,  not  much 
attention  has  been  paid  to  develop  proper  data  management  techniques. 
Only  a  few  research  studies  were  made  on  data  management  for  finite 
element  analysis.  Lopez  (1978)  and  associates  studied  the  application 
of  data  management  to  structures.  They  pointed  out  that  serious 
drawbacks  of  ASKA,  STRUDL  and  NASTRAN  were  due  to  lack  of  high  level 
database  management  facility.  Also,  these  programs  did  not  provide  any 
type  of  data  structure  capability.  They  have  simple  internal 
organization  and  require  many  files  with  trivial  data  structures.  These 
type  of  system  tend  to  be  I/O  bound  because  logical  operations  on  data 
are  related  directly  to  a  physical  location  on  a  serial  device.  For 
example,  in  generating  the  stiffness  matrix  for  the  elements  of  a 
structure,  most  programs  generate  one  matrix  and  write  onto  a  sequential 
device;  and  the  process  is  repeated  for  all  elements  of  a  structure.  In 
order  to  access  these  stiffness  matrices  at  a  later  time,  the  program 
must  pass  serially  over  the  entire  file  again.  Lopez  (1974)  in  another 
paper  presented  a  data  management  system  for  finite  element  analysis. 
Pahl  (1981)  described  the  properties  and  functions  of  data  storage  for 
finite  element  programs. 

Several  research  studies  were  made  on  data  management  techniques 
for  computer-aided  design  and  general  engineering  applications.  The 
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techniques  developed  for  them  are  also  applicable  for  finite  element 
analysis  and  design  optimization.  Studies  on  data  models,  database 
design  methodology,  database  network,  data  definition  language,  data 
manipulation  language,  database  integrity  and  consistency  and  numerical 
database  management  were  conducted  by  several  researchers.  A 
comprehensive  survey  of  data  management  in  engineering  applications  is 
given  by  Sreekanta  Murthy  and  Arora  (1985a). 


The  well-known  data  models  —  hierarchical,  network  and  relational 
have  been  studied  by  many  researchers  to  find  out  their  suitability  for 
organizing  engineering  data.  Koriba  (1983)  discusses  applicability  of 
ANSI/SPARC,  CODASYL  and  relational  approach  to  CAD  software  design.  The 
three  levels  of  data  view  proposed  by  ANSI/SPARC  is  gaining  wide 
acceptance  and  is  likely  to  be  incorporated  into  future  CAD  systems. 
Relational  approach  is  based  on  set  concepts  and  provides  a  sound 
mathematical  background.  This  approach  provides  high  level  of  data 
independence,  user  friendly  data  definition  and  data  manipulation 
capabilities.  Relational  model  is  becoming  popular  among  database 
designers  and  users.  Several  researchers  are  currently  working  on  this 
model.  Fishwick  and  Blackburn  (1982)  discuss  advantage  and  disadvantage 
of  a  relational  model  from  an  engineering  point  of  view.  Authors 
provide  examples  of  relations  for  managing  data  of  a  finite  element 
model.  They  also  described  the  development  of  the  PRIDE  system  which 
integrates  engineering  application  programs  --  AD-2000,  SPAR,  PROSSS, 
NCAR ,  and  BANDIT.  SPAR  and  PROSSS  are  finite  element  analysis  and 
structural  iptimi /at i on  packages  respectively.  AD-2000  is  a  finite 


element  model  generator  and  BANDIT  is  bandwidth  optimization  program. 
However,  use  of  their  database  management  system  was  limited  to 
interfacing  application  program  input  and  output  to  a  common  database. 
Modification  of  application  programs  was  not  made  to  use  the  database 
for  programs  internal  data  organization  needs.  Blackburn,  Storaasli  and 
Fulton  (1982)  in  another  paper  demonstrate  the  use  of  a  relational 
database  in  engineering  applications.  Four  sample  problems  --  a  panel 
with  circular  hole,  a  square  plate,  a  conventional  wing  structure  and  a 
large  area  space  structure  were  used  to  evaluate  the  merits  of  managing 
engineering  data  using  a  relational  system.  Studies  on  hierarchical 
model  are  mainly  with  reference  to  organizing  large  matrices.  Lopez 
(1974)  uses  a  hierarchical  model  for  finite  element  data  organization. 
A  hierarchical  data  structure  for  organizing  node,  element,  load  and 
stiffness  matrix  data  is  given  in  the  paper.  However,  the  DBMS  uses  a 
problem-oriented  language  translating  facilities  in  the  POLO  supervisor 
under  which  the  application  programs  operate.  Hence,  it  is  highly 
doubtful  that  two  will  ever  be  used  independently  of  each  other.  Pahl 
(1981)  described  hierarchical  storage  structure  for  hypermatrix  data 
organization.  Hypermatrix  stiffness  and  load  data  are  found  to  be  most 
suitable  to  hierarchical  data  representation.  A  paper  by  Elliot,  Kunni , 
and  Browne  (  1978)  describes  a  hierarchical  model  of  data  and  a  DBMS 
system  design  based  on  it.  Some  practical  examples  on  structural  design 
and  wind  tunnel  data  management  are  also  given  in  the  paper.  But,  this 
system  requires  a  precompiler  to  decode  the  data  description  and  data 
manipulation  commands  in  a  source  program. 


Investigations  have  been  conducted  to  find  out  a  suitable  way  to 
design  a  database  for  engineering  applications.  There  exists  basically 
two  different  approaches  to  database  design  --  first  approach  generates 
a  global  schema  and  then  derive  local  views  from  it;  the  second  one 
obtains  local  views  of  different  users  and  then  integrate  them  to  form  a 
global  view.  Buchmann  and  Dale  (1979)  analyze  different  methodologies 
to  design  a  database  and  present  a  frame  work  for  evaluating  them.  A 
comprehensive  description  of  database  design  methodology  for  business 
applications  is  given  in  Vetter  and  Maddison  (1983).  Several 
researchers,  Lillehagen  and  Dokkar  (1982),  Grabowski ,  Eigener  and  Ranch 
(1978),  and  Eberlein  and  Wedekind  (1982)  have  worked  on  database  design 
for  CAD  applications.  So  far,  there  does  not  exist  any  methodology  to 
design  database  of  finite  element  and  design  optimization  programs. 

Development  of  suitable  data  definition  (DDL)  and  data  manipulation 
languages  for  engineering  applications  have  been  of  interest  to  many 
researchers.  One  of  the  major  considerations  in  the  design  of  data 
definition  language  was  to  keep  the  syntax  concise  and  easy  to  use  for 
application  programmers.  Several  other  important  considerations  in  DDL 
design  are  described  in  detail  by  Elliot,  Kunni  and  Browne  (1978).  They 
use  special  indicators  in  the  source  program  code  to  identify  the  DDL 
and  DML  commands  and  translate  tnem  using  a  precompiler  to  FORTRAN 
statements.  These  DDL  and  DML  statements  can  be  used  to  operate  on  a 
hierarchical  data  structure.  Special  features  of  DDL  and  DML  in  a 
relational  DBMS  for  interactive  design  are  described  by  Shenoy  and 
Patnai k  (  1983)  . 


The  application  of  data  management  in  numerical  computation  is 
fairly  new.  Finite  element  analysis  and  design  optimization  procedures 
require  substantial  amount  of  matrix  data  processing.  Data  management 
system  require  special  facilities  to  deal  with  data  of  large  matrices. 
A  recognition  of  this  need  is  made  by  Daini  (1982)  and  a  model  is 
developed  for  numerical  database  arising  in  many  scientific  applications 
to  keep  track  of  large  sparse  and  dense  matrices.  The  paper  describes  a 
generalized  facility  for  providing  data  independence  by  relieving  users 
from  the  need  for  knowledge  of  physical  data  organization  on  the 
secondary  storage  devices.  Because  of  the  limitation  of  core  storage 
and  to  reduce  the  input-output  operations  involved  in  secondary  storage 
techniques,  many  investigations  have  been  conducted  on  the  efficient  use 
of  primary  memory.  A  detailed  survey  by  Pooch  and  Nieder  (1973)  gives 
various  indexing  techniques  that  can  be  used  in  dealing  with  sparse 
matrices.  Darby-Dowman  and  Mitra  (1983)  describe  a  matrix  storage 
scheme  in  linear  programming.  Rajan  and  Bhatti  (1983)  described  a 
memory  management  scheme  for  finite  element  software.  Sreekanta  Murthy, 
Reddy  and  Arora  (1984)  describe  the  database  management  concepts  that 
are  applicable  to  design  optimization  field. 

1.5  Objectives  of  Research 

1.  To  study  of  various  database  management  concepts  applicable  to 
computer-aided  structural  design  optimization  field.  Suitability  of 
available  database  management  concepts  and  drawbacks  associated  with 
their  use  in  engineering  design  will  be  investigated. 


2.  To  develop  a  suitable  database  design  methodology  for  structural 
design  database  and  to  develop  a  conceptual  data  model  to  represent 
the  design  data.  Schemes  for  constructing  internal  and  external 
data  models  will  be  identified.  Data  models  for  organizing  matrix 
data  will  be  developed. 

3.  To  study  the  existing  database  management  systems  and  to  identify 
the  important  features  with  respect  to  their  suitability  to  organize 
structural  design  data. 

4.  To  formulate  requirements  of  data  definition  language,  data 
manipulation  language  and  query  language  for  engineering  design 
database  management  system. 

5.  To  implement  a  database  management  system  for  engineering 
applications  based  on  selected  data  models. 

6.  To  design  a  database  for  structural  design  optimization.  Use  of 
database  design  methodology  for  constructing  conceptual,  internal 
and  external  model  will  be  demonstrated. 

7.  To  implement  a  computer-aided  structural  design  optimization  program 
using  a  database  management  system  and  evaluate  its  performance. 


1.6  Scope  of  Work 

Computer-aided  structural  design  process  is  identified  in 
Chapter  2.  Mathematical  modelling  for  finite  element  analysis  and 
structural  design  optimization  are  given.  Need  for  database  management 
in  structural  design  is  stressed.  Chapter  3  deals  with  database 
management  concepts.  Well-known  data  models  are  described  with 
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reference  to  structural  design  data.  Various  database  management 
concepts  like  normalization  of  data,  and  global  and  local  databases  are 
described.  Database  design  methodology  for  structural  design  is  given 
in  Chapter  4.  Methodology  for  conceptual  model  development  for 
structural  design  database  is  described.  Normalization  procedures  for 
developing  internal  data  model  are  described  with  examples.  Description 
of  a  proposed  numerical  model  is  given  there.  In  Chapter  5, 
requirements  of  a  database  management  system  are  studied.  Requirements 
of  data  definition  and  data  manipulation  languages  for  structural  design 
database  are  formulated.  Considerations  in  developing  memory  management 
schemes  and  query  language  are  presented.  Implementation  details  of  a 
database  management  system  for  organizing  structural  design  data  are 
described  in  Chapter  6.  Relational  data  management  procedures  and 
numerical  data  management  schemes  are  described.  Usefulness  and 
drawbacks  of  this  systems  are  given.  In  Chapter  7,  database  design  for 
structural  optimization  is  described.  An  evaluation  of  database  design 
methodology  is  given.  Computer  program  developed  for  finite  element 
analysis  and  structural  design  optimization  is  described  in  Chapter  8. 
The  capabilities  of  the  program  and  example  problems  solved  using  it  are 
given  there.  In  Chapter  9,  evaluations  of  the  database,  the  database 


management  system,  and  the  computer  program  for  structural  optimization 
are  made.  Finally,  discussion  and  conclusions  of  the  present  study  are 
given  in  the  last  chapter. 


CHAPTER  2 


COMPUTER-AIDED  STRUCTURAL  DESIGN 

2.1  Introductory  Remarks 

In  this  chapter,  the  principles,  methods  and  tools  required  to 

develop  a  computer-aided  design  of  structural  system  are  described. 

Structural  design  process  is  described  with  the  aid  of  a  sample  design 
problem  to  provide  qualitative  description  of  the  design  process.  In 
particular,  mathematical  modelling  of  the  structural  design  process  is 
given  in  Section  2.3  to  bring  out  various  steps.  As  mentioned  in 

Chapter  l,  a  database,  a  program  library  and  a  communication  link  form 
the  important  components  of  a  CAD  system.  These  components  are 

described  in  detail  in  Section  2.4.  Need  for  data  management  for 

structural  design  is  emphasized  in  Section  2.5.  Need  for  a  good 

communication  subsystem  is  given  in  Section  2.6.  Finally,  various 

classes  of  users  of  a  computer-aided  structural  design  system  and  their 
requi rements  are  identified  in  the  last  section. 

2.2  Structural  Design  Process 
and  a  Sample  Design  Problem- 

A  study  of  overall  structural  design  process  is  necessary  to 

develop  a  computer-aided  structural  design  system.  The  design  process 
can  be  described,  in  general,  by  a  sequence  or  chains  of  actions  where 
each  action  passes  its  results  on  to  its  successors.  The  complex  nature 


of  design  process  will  have  to  be  reflected  in  CAD  systems  if  such 
systems  are  to  support  the  design  process  as  a  whole. 

The  design  process  begins  with  the  identification  of  a  need  by  a 
user  of  the  structural  system.  The  needs  and  objectives  of  the  system 
are  defined  quantitatively.  Functional  analysis  is  carried  out  to  find 
out  operational  requirements  of  the  structural  system.  The  next  step  is 
the  configuration  or  conceptual  design  of  the  system.  For  example,  if 
function  to  be  performed  is  to  support  the  loads  on  a  frame,  the 
conceptual  design  (see  Fig.  2.2.1)  includes  beams,  columns,  plates,  and 
bars.  At  the  conceptual  design  stage  various  parameters  describing  the 
system  are  identified  and  acceptable  range  of  values  are  prescribed. 


This  preliminary  design  is  then  analyzed  with  respect  to  the  constraints 
and  if  it  does  not  adequately  satisfy  the  constraints,  the  design  is 
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structural  system  capability  or  minimization  of  cost.  The  analysis  and 
redesign  cycles  are  repeated  until  a  design  satisfying  all  the 
constraints  is  obtained. 

It  is  common  that  a  number  of  designers  working  on  a  practical 
design  project  carry  out  specific  subtasks.  Designers  are  required  to 
meet  individual  goals,  and  may  have  an  isolated  view  of  the  project. 
For  example,  designer  A  (see  Fig.  2.2.2)  may  work  only  on  part  of  the 
structure  in  the  design  project.  During  the  process,  a  set  of 


information  required  for  individual  needs  is  derived  to  carry  out  the 


specific  task.  The  sharing  of  information  takes  place,  between  the 
conceptual  design  level  with  subsystem  design  levels,  and  among 
subsystem  design  levels  themselves.  The  method  of  information  sharing 
(reports,  catalogues,  etc.  in  case  of  conventional  design  process;  a 
database  in  case  of  CAD  design  process)  and  tools  for  information¬ 
sharing  (typing,  printing,  drafting  in  conventional  design;  interactive 
computer  terminals,  graphics  in  CAD  design  process)  are  dependent  on  the 
state-of-art  of  the  design  process. 

2.3  Mathematical  Modelling  of  Structural  Design 

In  the  previous  section,  a  general  structural  design  process  was 
described.  Here,  mathematical  modelling  for  structural  design  is 
given.  This  mathematical  model  is  intended  to  provide  a  basic  framework 
for  developing  a  computer-aided  structural  design  system.  Various  steps 
of  the  structural  design  are  formulated  in  terms  of  mathematical 
models.  Namely,  identification  of  objectives  and  constraints,  analysis 
of  the  structure  by  the  finite  element  method,  design  constraint  checks, 
design  sensitivity  calculations,  and  design  optimization  process  are 
described . 


2.3.1  Finite  Element  Analysis 

Finite  element  analysis  begins  with  idealization  of  the  structure 
using  a  number  of  finite  elements.  The  input  data  for  a  finite  element 
analysis  program  consists  of  the  geometric  idealization,  the  material 
properties,  and  the  loading  and  boundary  conditions.  Important  steps  of 


finite  element  analysis  (Cook,  1981)  are  listed  below.  Depending  on  the 
type  of  analysis,  some  or  a  combination  of  the  steps  are  used. 


Element  Level  Computation.  At  the  element  level,  stiffness 
matrices,  mass  matrices,  load  matrices  are  computed  as 


K  =  /  B  D  B  dV 


M  =  /  N1 p  N  dV 


pe  =  P0  +  Ps  +  PB 
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Substructure  Level  Computation.  If  substructures  are  used  in  the 
idealization,  then  element  stiffness  matrices  are  assembled  to  form 
substructure  level  matrices.  The  equilibrium  equation  for  the  rth 
substructure  is  given  by 


KrUr  =  Pr 
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The  following  computations  are  done 


p 

„r  „r  „r  .,-1  „r 
*S)  -  Sb  -  ^i  *  Kii  •  Kib 

*r  r  -lr  r 

Pb  =  <i  *  *i1  *  Pi 

Keff  =  l  < 
r 

Peff  ‘l  "^b  +  Pb 

r 

Structure  Level  Computation.  Equations  of  equilibrium  for  the 
complete  structure  are  solved  to  get  response  of  the  structure.  For 
static  equilibrium,  we  have 


KU  =  P 


where 


K  =  l  K  ,  P  =  l  PQ 

L  e  L  e 

n  n 

For  dynamic  response  of  a  linear  structural  model. 


MU  +  CU  +  KU  =  P 


where 


H  -  l  Me,  C  =  l  Ce,  P  -  l  Pe 


For  nonlinear  analysis 


(k£  +  kJl)  ^ =  pt 


For  buckling  analysis 


(K  +  XK  )  U  =  0 


For  frequency  analysis 


(K  +  XM)  U  =  0 


Recovery  of  Element  Level  Response.  After  the  structure  level 
response  have  been  computed,  element  level  displacements,  stresses, 
strains,  and  forces  are  computed 


uo  =  TU 
e 


e  =  Bu 
e  e 


•  y*y  y  .*•  \ 

<■  -/‘o's  '  /■' .  ,  ■ 


*  /  */  *  -  ’  .  »  .  •  .  *  .  *  k  .  ._•  .  '  %«>%  -  .  »  ,  -  ,*t 


2.3.2  Optimal  Structural  Design 

Optimal  structural  design  is  carried  out  using  well-known  methods 
given  in  Haug  and  Arora  (1979)  and  Arora  and  Govil  (1977).  Important 
steps  of  optimal  design  consist  of  formulation  of  cost  and  constraint 
functions,  checking  for  constraint  violations,  design  sensitivity 
analysis,  design  change  computations  and  convergence  checks.  These 
steps  are  listed  below. 


Problem  Formulation.  Optimal  structural  design  problem  is 
formulated  using  a  set  of  state  and  design  variables.  The  objective  is 
to  minimize  the  cost  function 


*0(z,  C,  b) 


subject  to  state  equations 


h(z,b)  =  0 
K(b)y  =  cH(b)y 


and  constraints 
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Constraint  Checks.  Violated  displacements,  stress,  frequency  and 


m 


other  constraints  are  identified.  For  displacement  constraints 
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For  eigenvalue  constraint 
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For  stress  constraints 
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For  buckling  constraint 
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For  design  variable  constraints 


ip.  =  b.  -  b.  <  0,  or  b..  -  b.  <  0 
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Design  Sensitivity  Analysis.  Design  sensitivity  analysis  is  done 
to  determine  the  effect  on  the  problem  functions  of  a  change  in 
design  6b  in  b°.  Gradients  of  function  is 
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The  following  computations  are  needed  to  calculate  gradients: 


1.  Linear  systems 


for  direct  differentiation  method 


KT  X, 


for  adjoint  variable  method 


IE  =  IB  ) 


2.  Nonlinear  systems  (Ryu,  Haririan,  Wu  and  Arora,  1984) 


t  J  j  .  3*i 
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Sensitivity  analysis  of  eigenvalues 
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Design  Change  Computation.  A  change  in  design  variable  vector  b  is 


computed  to  reduce  the  cost.  Mathematical  programming  methods  such  as 


the  gradient  projection  or  other  methods  (Arora,  et  al.,  1984b)  are  used 


to  compute  design  change  5b: 
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A  general  flow  diagram  for  optimal  design  of  the  structure  is  given 


in  Fig.  2.3.1. 


2.4  Components  Required  to  Develop 
Computer-Aided  Structural  Design  System 

For  developing  a  computer-aided  structural  design  system  three 

important  components  --  a  database,  a  program  library,  and  a 

communication  subsystem  are  required.  A  database  contains  data  required 

for  finite  element  analysis  and  structural  design  optimization.  Several 

users  operate  on  the  database  either  interactively  or  though  application 

programs.  A  database  acts  as  a  central  repository  of  data  for  CAD 

applications.  The  second  component,  namely,  a  program  library  contains 

both  the  modules  used  for  data  management  and  modules  containing 

algorithms  needed  for  structural  analysis  and  design  applications 

(matrix  operation  library,  equation  solvers,  finite  element  programs  and 

optimization  routines).  Data  management  programs  need  basic  components 

file  management,  input-output  processor,  memory  management, 

addressing  and  searching,  and  security  routines.  Finally,  a 

communication  subsystem  is  needed  to  provide  link  between  the  computer 

and  designer.  They  provide  channels  of  data  communication  between  the 

database,  database  management,  and  application  programs.  A 

communication  subsystem  consists  of  interactive  command  processors,  data 

definition  language,  data  manipulation  language,  and  routines  for 

graphic  display.  The  basic  components  of  a  computer-aided  structural 

design  system  are  schematically  shown  in  Fig.  2.4.1. 
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Figure  2.3.1  A  General  Flow  Diagram  for  Optimal  Design  of  Structure 


Figure  2.4.1  Components  of  Computer-Aided  Structural  Design  System 


Thus,  we  need  to  design  and  develop  the  three  components  --  a 
database,  a  program  library  and  a  communication  subsystem  to  provide  an 
efficient  and  economic  means  of  designing  a  structural  system  using 
computer.  In  this  study,  database  which  is  the  most  important  component 
of  the  system  is  considered  in  detail. 

2.5  Need  for  a  Database  in 
Computer-Aided  Structural  Design  Optimization 

In  optimal  design  of  structural  and  mechanical  systems,  we 
generally  use  nonlinear  programming  techniques  (Haug  and  Arora,  1979). 
The  design  objectives  and  constraints  for  the  system  are  described  in  a 
mathematical  model.  Design  of  a  system  is  specified  using  a  set  of 
parameters  called  design  variables.  The  design  variables  depend  on  the 
type  of  optimization  problem.  In  design  of  aircraft  components  such  as 
stiffened  panels  and  cylinders,  the  design  variables  are  spacing  of  the 
stiffeners,  size  and  shape  of  stiffeners,  and  thickness  of  skin.  In 
optimization  of  structural  systems  such  as  frames  and  trusses  of  fixed 
configuration  the  sizes  of  the  elements  are  design  variables.  Thickness 
of  plates,  cross-sectional  areas  of  bars,  moment  of  inertia  represent 
sizes  of  the  elements.  If  shape  optimization  is  the  objective,  the 
design  variables  may  include  parameters  related  to  geometry  of  the 
system . 

The  constraints  for  tne  system  are  classified  into  performance  and 
size  constraints.  The  performance  constraints  are  on  stresses. 


displacements,  and  local  and  overall  stability  requirements  in  the 
static  case;  frequencies  and  displacements  in  the  dynamic  case;  flutter 
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velocity  and  divergence  in  aeroelastic  case,  or  a  combination  of 
these.  The  size  constraints  are  the  minimum  and  maximum  value  of  design 
variables.  In  nonlinear  programming ,  the  search  for  the  optimum  design 
variable  vector  involves  iterative  schemes.  The  design  variable  data  at 
the  nth  iteration  is  used  to  compute  a  direction  vector  and  a  step  size 
along  it.  The  direction  vector  involves  computation  of  gradients  of 
objective  and  constraint  functions  with  respect  to  the  design 
variables.  Data  belonging  to  equivalent  design  variables  are  grouped 
there  by  reducing  the  size  of  design  variable  vector. 

In  most  problems  of  structural  and  mechanical  system  design, 
behavior  of  the  system  can  be  defined  using  state  variables,  e.g., 
stresses,  displacements,  and  other  response  variables.  In  such  a  case, 
state  space  formulation  is  frequently  employed  (Haug  and  Arora,  1979). 
Design  sensitivity  coefficients  in  terms  of  matrix  equation  are 
determined  in  state  space  formulation.  Adjoint  equations  are  used  to 
define  a  set  of  variables  that  provide  design  sensitivity  information. 
Symmetric  matrix  equations  can  be  used  to  advantage  thereby  reducing  the 
data  storage  requirements. 

Finite  element  and  other  numerical  methods  are  used  for  analysis  of 
structural  and  mechanical  systems.  Finite  element  method  uses  data  such 
as  element  number,  nodal  connectivity,  element  stiffness  matrix,  element 
mass  matrix,  element  load  matrix,  assembled  stiffness,  mass  and  load 
matrices,  displacement  vectors,  eigenvalues,  eigenvectors,  buckling 
modes,  decomposed  stiffness  matrix,  and  the  stress  matrix.  In  general 
data  used  in  finite  element  and  other  numerical  analysis  procedures  is 


quite  large.  Symmetry  of  stiffness  and  mass  matrices  is  taken  into 
account  so  that  data  storage  requirement  is  reduced.  Hypermatix  or 

other  special  schemes  are  generally  used  in  dealing  with  large  matrix 
equat i ons . 

For  design  of  large  structures,  efficient  design  sensitivity 
analysis  is  particularly  critical.  For  such  structures,  substructuring 
concept  can  be  effectively  integrated  into  structural  analysis,  design 
sensitivity  analysis,  and  optimal  design  procedures  (Haug  and  Arora, 
1979'.  In  this  concept,  one  deals  with  small  order  matrices  as  the  data 
can  be  organized  substructure-wi se.  The  degrees  of  freedom  can  be 
classified  into  boundary  degrees  of  freedom  and  interior  degrees  of 

freedom.  Data  for  the  stiffness  matrices  corresponding  to  these  degrees 
of  freedom  can  be  separately  stored.  Data  of  constraint  functions 

correspond! ng  to  internal  and  boundary  degrees  of  freedom  are  used  in 
ueternining  design  sensitivity  calculations.  Adjoint  matrix  data  is 

stored  for  each  substructure. 

Many  real  world  problems  will  have  features  that  are  not  explicitly 
contained  in  general  optimal  design  formulation.  Problems  with  peculiar 
features  need  to  be  treated  by  making  minor  alterations  in  the  general 
algorithm.  Interactive  computation  and  graphics  can  be  profitably 
employed  m  design  optimization.  At  a  particular  iteration,  the 
designer  can  study  the  d3ta  of  design  variables,  constraints  which  are 
active,  performance  of  the  system,  cost  function,  admissible  direction 
of  travel,  sensitivity  coef f i cients ,  etc.  He  can  make  judgement 
regarding  suitability  of  a  particular  algorithm,  change  of  system 
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parameters,  and  redefine  convergence  parameters  to  achieve  optimal 
design.  Interactive  graphics  requires  additional  data  for  display  of 
system  model,  results,  and  graphs. 

Thus,  for  design  optimization,  data  generated  during  analysis  must 
be  saved  in  the  database.  This  data  is  used  for  formulation  of 
constraints.  Constraints  are  checked  for  violation.  Design  sensitivity 
analysis  of  violated  constraints  is  carried  out  using  most  of  the  data 
generated  during  analysis.  Once  design  sensitivity  analysis  has  been 
completed,  a  direction  finding  problem  is  defined  and  solved.  Note  that 
the  size  of  direction  finding  problem  at  each  iteration  depends  on  the 
number  of  active  constraints.  Therefore,  sizes  of  data  sets  change  from 
iteration  to  iterations.  Thus,  the  nature  of  data  is  quite  dynamic.  We 
should  be  able  to  dynamically  create  large  data  sets,  manipulate  them 
during  the  iteration,  and  delete  some  of  them  at  the  end  of  iteration. 
Useful  trend  information  from  each  iteration  must  be  saved  for 
processing  in  later  iterations.  Note  that  a  row  of  the  history  matrix 
(such  as  design  variable  values)  is  generated  at  each  iteration. 
However,  to  use  the  trend  information  for  a  quantity  (e.g.,  a  design 
variable),  we  need  to  look  at  its  value  at  the  previous  iterations. 
This  implies  that  we  should  look  at  a  column  of  the  history  matrix. 
Therefore,  we  should  be  able  to  create  data  in  one  form  and  view  it 
another.  Thus,  we  must  have  an  intelligent  and  sophisticated  DBMS. 
Data  must  be  organized,  saved  in  a  database,  and  properly  managed  for 
design  optimization. 

We  observed  that  large  amount  of  computation  is  needed  in  the 
design  process.  Finite  element  analysis  and  optimization  programs 
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generate  large  amount  of  data  depending  on  the  size  of  the  problem.  The 
amount  of  data  used  during  design  optimization  stage  depends  directly  on 
the  number  of  iterations.  Several  application  programs  are  used  during 
the  design  process  and  each  of  them  requiring  specific  data.  Several 
algorithms  may  be  needed  which  use  similar  data  to  arrive  at  optimal 
design.  In  such  a  case  data  used  by  one  algorithm  should  be  made 
available  for  use  in  another  algorithm.  Therefore,  designer  needs 
control  to  select  appropriate  algorithm  and  data  to  obtain  optimum 
solution.  An  important  feature  of  design  database  is  that  it  contains 
both  informative  data  such  as  geometry,  material  property  as  well  as 
operational  data  such  as  stiffness  matrix.  Informative  data  remains 
static  where  as  operational  data  gets  continuously  updated,  modified  and 
deleted.  A  centralized  database  is  needed  which  stores  all  the  data  of 
analysis  and  design.  A  centralized  database  provides  an  option  for  the 
designer  to  interrupt  the  program  execution  and  provides  flexibility  for 
the  designer  to  change  the  design  parameters.  Therefore,  a  careful 
consideration  of  data  organization  in  a  database  is  necessary  to  improve 
design  efficiency. 

In  summary,  we  have  identified  the  need  for  a  database  for 
structural  design  and  special  nature  of  the  data  was  highlighted. 


Communication  Subsystem 


In  this  section,  we  emphasize  the  need  for  a  good  communication 
subsystem  of  computer-a ided  structural  design  system.  A  good 
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communication  link  is  possible  through  a  well  defined  languages  for 
interaction  between  the  computer  and  the  designer.  Also,  computer 
graphics  provides  an  effective  channel  of  communication. 

Languages  for  interaction  are  used  either  through  application 
program  or  interactively  using  a  computer  terminal.  Finite  element 
analysis  and  design  optimization  application  programs  interact  with  the 
computer  to  define  and  manipulate  data  in  the  database.  Data  definition 
and  data  manipulation  languages  are  provided  for  this  purpose.  These 
languages  are  generally  a  set  of  commands/subroutine  call  statements  in 
the  host  language.  It  is  essential  to  design  these  languages  such  that 
they  are  simple  and  easy  to  use.  In  an  interactive  mode,  data 

definition  and  manipulation  is  done  using  a  query  language.  A  general 

set  of  interactive  commands  must  be  available  in  the  system. 
Requirements  and  implementation  of  these  languages  are  discussed  in 
later  chapters. 

Finite  element  analysis  and  design  optimization  algorithms  produce 
huge  amount  of  data.  In  order  to  make  these  results  useful  for 

i nterpretation  and  evaluation,  they  need  to  be  presented  in  a  readily 
understandable  form.  Long  list  of  printed  data  are  not  suited  for 

comprehension.  Graphical  presentations  are  appropriate  solutions. 
Typical  tasks  of  computer  graphics  include  the  selection  of  visual  aids 
(graphic  displays,  fast  plotters),  editing  of  data  to  be  displayed, 
command  interpretation  and  graphic  database  management.  Therefore,  a 
wel 1 -devel oped  command  language  and  computer-yraphics  can  offer 
considerable  aid  to  designer  to  communicate  effectively  with  the 


computer  during  the  design  process. 


2.7  Users  of  Computer-Aided 
Structural  Design  System 

We  have  to  identify  different  users  of  computer-aided  structural 
design  system  and  their  needs.  Three  types  of  users  are  identified  -- 
(i)  the  system  programmers  (ii)  application  programmers  and 
(iii)  interactive  users.  The  difference  between  these  users  and  the  way 
they  use  the  system  are  described  below. 

System  programmers  are  those  who  develop  general  purpose  programs 
for  structural  analysis  and  optimization.  In  general,  persons  who  write 
these  programs  are  not  the  same  as  those  who  apply  them.  They  work  on  a 
very  high  level  of  data  abstraction.  They  need  a  good  database 
management  system,  matrix  operation  and  utility  library,  and  a  graphic 
system.  There  exists  a  second  category  of  system  programs  who  modify 
the  existing  general  purpose  finite  element  programs  to  add  new 
capability  to  the  programs.  Some  programs  like  GIFTS,  ADINA,  and  SPAR 
have  excellent  analysis  capability.  However,  many  of  these  systems  do 
not  have  database  management  facility  capable  of  sharing  data  outside 
the  program  environment.  In  some  of  these  programs,  a  local  data 
management  routines  are  used.  These  programs  can  be  incorporated  into 
structural  design  system  by  providing  an  interface  between  the  database 
and  the  programs  or  by  modification  of  program  to  retrieve  essential 
data  that  program  requires.  Pre-  and  post  processing  capabilities  of 
these  programs  together  with  their  local  database  may  be  used  to 
integrate  tnem  in  the  design  process. 

The  application  programmers  are  much  closer  to  practical 
applications.  Their  interest  is  not  to  provide  means  for  general 


problem  solution,  but  to  solve  special  problems;  e.g.,  stress  analysis 


of  a  structure  for  a  certain  number  of  load  combinations.  In  yeneral 
the  packaged  programs  may  not  have  capabilities  to  handle  special  needs 
of  the  problem.  For  this  reason  the  application  programmers  need 
capabilities  to  exchange  data  between  subsystems  and  add  their  own 
algorithm  whenever  the  subsystems  are  not  completely  covering  their 
needs.  Consider,  for  example  a  finite  element  package  in  which 
capability  to  include  special  boundary  conditions  does  not  exist. 
Application  programmer  in  that  case  selects  an  appropriate  algorithm  for 
assembly  and  solution  of  system  of  equations  to  meet  the  needs.  Design 
optimization  procedures  have  similar  needs  for  selecting  alternate 
application  programs.  Depending  on  convergence  and  other  requirements, 
designer  switches  to  appropriate  optimization  algorithm,  but  essentially 
using  almost  the  same  data. 

Interactive  users  are  those  who  use  the  same  application  program 
many  times  by  changing  only  certain  parameters.  This  type  of  users  do 
not  worry  about  complicated  descriptive  or  algorithmic  facilities. 
Their  concern  is  data  input  for  many  iterations  with  minimum  effort  on 
and  easy-to-percei ve  representat ion  o‘  output.  An  interactive  user  of 
finite  element  system  may  like  to  so*  to*  •>*%>:  t  of  introducing  a 


boundary  condition  at  a  particular  "ode 
using  an  optimization  package  may 
for  various  values  of  step  s-ze  'nc-M-n. 

Thus,  we  have  ident  i  ‘  i  tn«. 
aided  structural  design  sys*>‘r. 
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i  CHAPTER  3 

' 

'  A  STUDY  OF  DATABASE  MANAGEMENT  CONCEPTS 

i 

3.1  Introductory  Remarks 

In  the  previous  chapter,  we  studied  the  structural  design  process 
and  emphasized  the  importance  of  database  management  concepts  in 
computer-aided  structural  design.  One  of  the  objectives  of  this 
research  is  to  study  various  database  management  concepts.  In  this 
chapter  this  study  is  made  to  understand  various  methods  available  for 
data  organization  and  to  implement  them  for  structural  design 

applications.  The  concepts  are  explained  with  reference  to  finite 
element  analysis  and  design  optimization  examples.  Before  the  concepts 
are  described  problems  in  developing  a  good  database  are  posed  in 

Section  3.2.  In  Section  3.3,  various  database  management  terminologies 
are  described,  since  they  are  relatively  new  to  engineering  community. 
In  Section  3.4,  commonly  used  data  models  are  evaluated  in  view  of 
organizing  structural  design  data  and  suitable  data  models  are  selected 
for  further  study.  Concepts  of  normalization  of  data  is  given  in 
Section  3.5.  Finally,  the  concept  of  global  and  local  databases  is 

explained  in  Section  3.6.  Based  on  these  studies;  a  technical  paper  has 
been  recently  accepted  for  publication  (Sreekanta  Murthy  and  Arora, 

1986). 


3.2  Problems  Associated  in  Providing 
a  Good  DBMS  for  CAD-OPT 

Now,  our  problem  is  how  the  database  has  to  be  organized?  what  kind 
of  information  is  to  be  stored?  what  kind  of  database  management  system 
(DBMS)  is  suitable?  how  data  is  manipulated?  and  how  various  finite 
element  analysis  and  design  optmization  applications  use  the  data? 
These  problems  have  to  be  studied  in  detail.  Data  handling  techniques 
in  existing  finite  element  analysis  programs  are  primitive  and  difficult 
to  use.  Moreover,  they  offer  little  flexibility  to  extend  them  for 
design  optimization  applications.  As  new  methods  of  design  evolve, 
there  is  a  need  to  incorporate  the  information  required  by  them  in  the 
database.  Thus  it  is  necessary  for  the  existing  database  to  be  flexible 
and  allow  simple  modifications.  The  increasing  size  of  database  and 
complexity  of  information  content  introduces  a  new  dimension  to  the 
problem  of  inconsistency  of  data.  The  operational  data  creates  update 
consistency  problems.  If  informative  data  are  changed,  the  operational 
data  must  be  invalidated.  Thus,  the  problem  of  data  dependency  which 
arises  from  storing  operational  data  together  with  informative  data 
influence  the  design  of  database. 

Abstract  structural  design  information  must  somehow  be  modeled  into 
the  computer.  This  modelling  aspect  of  actual  design  data  requires  a 
formal  approach.  In  this  regard,  sophisticated  techniques  are  available 
in  business  database  management  area  to  deal  with  complex  data 
Of'gani  zation  problems.  But  the  question  arises  as  to  whether 
engineering  data  could  be  similarly  modeled?  If  so,  do  the  structural 
design  databases  require  different  performance  consideration  from  the 
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database  or  commerical  applications?  These  questions  have  not  yet  been 
adequately  answered.  Several  different  approaches  have  to  be  taken;  for 
example,  use  of  commercially  available  database  systems,  and  development 
of  special  structural  design  database  systems.  Further,  the  data 
modelling  considerations  depends  on  the  type  of  user  and  application 
programs  as  discussed  earlier.  Requirements  of  users  and  application 
programs  must  be  considered  for  providing  a  good  database  organization 
for  structural  design. 

3.3  Definition  of  Various  Terminologies 

A  number  of  terminologies  and  definitions  are  given  to  facilitate 
descriptions  in  subsequent  chapters.  They  start  with  simple  ones  and 
move  on  to  more  complex  ones.  These  terminologies  are  new  to 
engineering  community  and  are  explained  here  with  examples  from  finite 
element  analysis  and  structural  design  applications. 

Database.  A  database  is  defined  as  a  collection  of  interrelated 
data  stored  together  without  harmful  or  unnecessary  redundancy  to  serve 
multiple  applications.  The  data  are  stored  so  that  they  are  independent 
of  programs  which  use  them.  A  common  and  controlled  approach  is  used  in 
adding  new  data  and  in  modifying  and  retrieving  existing  data  within  the 
database.  The  data  is  structured  so  as  to  provide  a  foundation  for 
future  application  development.  One  system  is  said  to  contain  a 
collection  of  databases  if  they  are  entirely  separate  in  structure 
(Martin,  1977). 


Logical  Data  Structure.  Data  in  a  particular  problem  consists  of  a 
set  of  elementary  items  of  data.  An  item  usually  consists  of  single 
element  such  as  integer,  real  and  character  or  a  set  of  such  items.  The 
possible  ways  in  which  the  data  items  are  structured  define  different 
logical  data  structures.  Therefore,  it  is  the  data  structure  as  seen  by 
the  user  of  the  DBMS  without  any  regard  to  storage  details. 


Model.  The  logical  structure  of  data. 


Schema.  The  coded  form  of  logical  data  structure  is  called  schema. 


Data  Independence.  It  is  the  property  of  being  able  to  change  the 
overall  logical  or  physical  structure  of  data  without  changing  the 
application  program's  view  of  the  data  (Martin  1977). 


Entity.  An  entity  may  be  'anything  having  reality  and  distinctness 
of  being  in  fact  or  in  thought'  (Vetter  and  Maddison,  1981).  An  entity 
may  be:  (i)  a  real  object  like  structure,  material;  (ii)  an  abstract 
concept  like  finite  element,  nodes,  a  time  period;  (iii)  an  event,  i.e., 
a  situation  that  something  is  happening  (e.g.,  vibrating  structure);  and 
(iv)  a  relationship,  e.g.,  elements  of  a  particular  type. 


Entity  Set.  An  entity  set  is  a  collection  of  entities  of  the  same 
type  that  exist  at  a  particular  instant,  e.g.,  set  of  finite  elements 
(ELEMENTS)  and  set  of  nodes  (NODES). 


Property.  Property  is  a  named  characteristic  of  an  entity,  e.g., 
element  name,  and  element  material  type.  Properties  allow  one  to 
identify,  characteri ze ,  classify  and  relate  entities. 
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Property  Value.  It  is  an  occurrence  of  a  property  of  an  entity, 
e.g.,  'element  name1  has  property  value  BEAM. 

Entity  Type.  Entities  having  same  kind  of  properties  are  said  to 
be  of  same  type.  Upper  case  letter  is  used  for  its  name. 

Domain.  A  domain  is  the  set  of  eligible  values  for  a  property.  A 
domain  has  same  characteristics  as  a  set,  i.e.,  the  values  belonging  to 
a  domain  are  distinct  and  their  order  is  immaterial.  A  predicate  is 
associated  with  each  domain  allowing  one  to  determine  whether  a  give,, 
value  belongs  to  the  domain  in  question.  Thus,  the  formal  definition  of 
domain  D<  is 

0 ■  =  { v j  P ^  }  where  v^  represents  a  value  satisfying  the 

predicate 

Examples  of  domain  are 

Element  Name  =  {BEAM,  TRUSS,  . } 

Element  Material  type  =  {STEEL,  ALUMINUM,  . } 

Length  =  {x|x  >0  and  x  <  100 } 

Attributes.  Columns  of  a  two-dimensional  table  are  referred  to  as 
attributes.  An  attribute  represents  use  of  a  domain  within  a 
relation.  Attribute  names  are  distinct  from  those  of  the  underlying 
domains;  e.g., 

NODES  =  • i ! i  >  0  and  i  <  n } 

DOFS  =  {j  1  j  >0  and  j  <  m} 


Domains : 


Attributes : 


N0DE1  -  First  node  of  an  element  derived  from 


domain  NODES 

DOF  1  -  First  d.o.f.  derived  from  domain  DOFS 
Relation:  ELEMENT(E* ,  NODEi,  N0DE2 ) 

'  Attributes  NODEI,  NODE?  and  derived  from  domain 

NODES 

i 

i 

Entity  Key.  An  entity  key  is  an  attribute  having  different  values 
for  each  occurring  entity  and  provide  unique  identification  of  a 
j  tuple.  An  entity  represents  a  compound  key  if  it  corresponds  to  a  group 

of  attributes.  It  is  also  called  candidate  key. 

Primary  Key.  If  several  entity  keys  exist  for  a  given  entity  set, 
then  one  of  them  is  arbitrarily  choosen  as  the  primary  key. 

Secondary  Key.  It  is  an  attribute  that  does  not  have  different 
values  for  each  occurring  entity,  but  identifies  those  occurring 

entities  that  have  certain  property. 

Relation.  R  is  a  relation  on  the  domains  (i.e., 

sets)  D^,  Or,  •••  Dn  (not  necessarily  distinct)  if  it  is  a  subset  of 

cartesian  product  xD^x. • »xDn .  Thus  R  c  D^xD^x'^xD^.  The  value  n 
represents  the  degree  of  the  relation  R.  The  relation  R  is  usually 
written  as 

R^,  D2,  •••,  Dn) 

Here  D, ,  D0,  D  are  called  attributes  of  the  relations.  The  values 

1  2  ’  n 

j  of  the  attributes  are  taken  from  the  corresponding  domains  for 

i 

I 

I 

I 

* 

I 


D 1 ,  ^2.  •••»  Dn.  Note  that  domain  is  a  set  of  values  where  as  attribute 
is  a  list  of  values  (Vetter  and  Maddison,  1981). 

Tuple.  Rows  of  a  relations  are  called  tuples. 

Function.  A  function  is  a  special  kind  oi  relation  between  two 
sets,  say,  A  and  B.  Each  member  of  a  set  A  is  associated  with  exactly 

one  member  of  set  B.  A  function  f  is  denoted  as 

f:  A+B 

Functional  Dependence.  An  attribute  A  is  functionally  dependent  on 
the  attribute  B  of  a  relation  R  if  at  every  occurrence  of  B-value  is 
associated  with  no  more  than  one  A-value.  This  is  denoted  as 
R.B  -  R.A 

Example.  As  an  example,  consider  the  relation 

ELEMENT  (ELMT# ,  EL-NAME,  AREA) 

EL-NAME  is  functionally  dependent  on  ELMT#.  AREA  is  functionally 
dependent  on  ELMT#.  ELMT#  is  not  functionally  dependent  on  EL-NAME, 

because  more  than  one  element  could  have  the  same  name.  Similarly, 

ELMT#  is  not  functionally  dependent  on  AREA. 

An  attribute  can  be  functionally  dependent  on  a  group  of  attributes 
rather  than  one  attribute.  For  example,  consider  the  relation  for  a 
triangular  finite  element: 

CONNECTION  ( N0DE1#,  N0DE2#,  N0DE3*,  ELMT#) 

Here  ELMTa  is  functionally  dependent  on  three  nodes  NODE  1  ^ ,  NODE?--, 
and  N0DE3*.  Given  any  one  of  NODEltf,  NODE?#,  or  N0DE3#  it  is  not 
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possible  to  identify  ELMT#.  Tnese  functional  dependencies  are  shown  in 
Fig.  3.3.1. 


Full  Functional  Dependency.  An  attribute  or  a  collection  of 
attributes  A  of  a  relation  R  is  said  to  be  fully  functionally  dependent 
on  another  collection  of  attributes  B  of  R  if  A  is  functionally 
dependent  on  the  whole  of  B  but  not  on  any  subset  of  B.  This  is  written 
as 

R.B  -*•  R.A 

In  the  Fig.  3.3.2  for  example,  ELMT#  in  the  relation  CONNECTION  of 
a  triangular  finite  element  is  fully  functionally  dependent  on 
concatenated  attributes  N0DE1#,  N0DE2#  and  N0DE3#  because  three  nodes 
combined  together  define  an  element.  NODE 1 # ,  N0DE2#,  or  N0DE3#  alone 
does  not  identify  ELMT# . 


Transitive  Dependence.  Suppose  A,  B  and  C  are  three  distinct 
attributes  or  attribute  collections  of  a  relation  R.  Suppose  the 
following  dependencies  always  hold:  C  is  functionally  dependent  on  B 
and  B  is  functionally  dependent  on  A.  Then  C  is  functionally  dependent 
on  A.  If  the  inverse  mapping  is  nonsimple  (i.e.,  if  A  is  not 

functionally  dependent  on  B  or  B  is  not  functionally  dependent  on  C) , 
then  C  is  said  to  be  transitively  dependent  on  A  (refer  to 
Fig.  3.3.3).  This  is  written  as 
R.A  ►  R.B 
“ . B  A  R.A 
R.B  >  R.C 


V  .*  VV  V 
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Then,  we  can  deduce  that 
R.A  +  R.C 


R.C  A  R.A 

For  example,  consider  the  relation 
EL-DISP( ELMT#,  EL-TYPE,  DOF/NODE) 


Here, 


Therefore 


ELMT#  +  EL-TYPE 
EL-TYPE  A  ELMT# 

EL-TYPE  >  DOF/ NODE 

ELMT#  >  DOF/NODE  (transitively  dependent) 
DOF/ NODE  A  ELMT# 


Digraph.  A  directed  graph  (refer  to  Fig.  3.3.4)  or  a  digraph  is  a 
figure  with  nodes  and  arcs.  Each  arc  is  a  line  with  a  direction.  Nodes 
represents  attributes  and  arcs  represent  dependencies  (functional,  fully 
functional).  Length  of  a  path  is  the  number  of  arcs  in  it.  For  example 
N1-A3-N2-A3-N3-A4-N2-A5-N4  has  length  4.  Distance  between  two  nodes  is 
the  longest  possible  path  between  them.  For  example  distance  between  N^ 
and  N4  is  4  since  longest  possible  path  between  nodes  is  N1-A1-N2-A3-N3- 
A4-N2-A3-N4  (Vetter  and  Maddison,  1981). 

Connectivity  Matrix.  Square  matrices  can  be  used  to  represent 
digraphs.  If  the  digraph  has  n  nodes  then  an  nxn  square  matrix  is 
used.  Rows  and  columns  represents  nodes.  Using  the  value  1  to  means 
presence  of  a  connection  and  the  value  0  to  mean  absence  of  a 
connection,  a  square  matrix  can  represent  the  connection  between  the 
nodes  of  a  digraph.  For  example,  if  node  2  is  connected  to  node  4,  then 
connectivity  matrix  is 
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N3 

n4 

N1 
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n2 
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n3 

0 

0 

0 

0 

n4 

0 

0 

0 
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Each  row  and  column  of  a  connectivity  matrix  is  named  the  same  as  the 
corresponding  node  (i.e.,  with  the  name  of  the  attribute  constituting 
the  node).  Appropriate  role  names  are  then  used  to  distinguish  multiple 
rows  and  columns  denoting  essentially  a  single  node  (Vetter  and 
Maddison,  1981). 


3.4  Views  of  Data  Used  in 
Structural  Design  and  Data  Model s 


Nature  of  data  used  and  computations  performed  in  finite  element 
analysis  and  structural  design  optimization  were  discussed  in  Sections 
2.2  and  2.5.  In  general,  data  used  in  design  can  be  viewed  as  single 
data  items,  vectors,  matrices,  tables,  etc.,  depending  on  the  nature  of 
data  and  the  context  in  which  they  are  used.  The  question  of  how  the 
design  data  should  be  organized  in  a  database  can  only  be  answered  by 
considering  a  formal  description  of  data  and  associations  among  them. 
The  most  elemental  piece  of  data  is  a  data  item.  It  cannot  be  further 
subdivided  into  smaller  data  type.  A  data  item  by  itself  is  not  of  much 
use.  It  becomes  useful  only  when  it  is  associated  with  other  data 
items.  Thus,  database  consists  of  data  items  and  the  association  among 
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them.  A  data  model  is  nothing  but  a  map  showing  different  data  items 
and  their  associations.  A  data  model  shows  logical  organization  of  data 
and  is  useful  to  describe  user's  view  of  data.  Layout  of  data  on 
physical  storage  devices  is  known  as  physical  organization. 

A  database  can  be  viewed  at  various  levels  depending  on  the 
context.  A  level  of  data  representing  view  of  interactive  terminal 
users  and  application  programmers  is  known  as  external  view.  Conceptual 
view  of  data  deals  with  inherent  nature  of  data  occurring  in  finite 
element  analysis  and  design  optimization  and  represents  a  global  view  of 
data  which  is  of  theoretical  interest.  The  data  organization  describing 
the  physical  data  layout  is  dealt  at  the  internal  level.  At  this  level, 
one  is  concerned  with  efficiency  and  storage  space  details.  There  is 
one  more  level  of  data  organization  below  the  internal  level  where  the 
actual  storage  of  data  on  a  particular  computer  system  becomes  the  main 
consideration.  But,  this  aspect  is  a  specialists  job  and  has  no  general 
guidelines.  Therefore,  it  is  not  discussed  here.  Three  levels  of  data 
-  external,  conceptual  and  internal  are  used  to  describe  various  views 
of  data.  These  levels  of  data  organization  were  suggested  by  ANSI/SPARC 
(American  National  Standard  Institute/Standard  Planning  and  Requirements 
committee).  They  are  considered  for  detailed  investigation  in  the  later 
chapters. 

In  the  following  subsections,  various  methods  available  for  data 
organization  are  evaluated  in  view  of  organizing  structural  design 
data,  suitable  data  models  are  selected  for  further  study. 
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3.4.1  Hierarchical  Model 


In  this  model,  the  data  is  represented  by  a  simple  tree 
structure.  A  tree  is  composed  of  a  hierarchy  of  elements  called 
nodes.  Every  node  (except  root)  has  a  node  related  to  it  at  a  higher 
level.  The  node  at  a  higher  level  is  called  a  parent  node.  Each  node 
can  have  one  or  more  nodes  related  to  it  at  a  lower  level  called  child 
nodes.  A  node  at  the  top  of  a  tree  is  called  the  root.  No  node  can 
have  more  than  one  parent.  A  hierarchical  model  has  one-to-many 
rel ationshi ps . 

In  finite  element  analysis,  we  can  form  a  hierarchical  model  with 
data  items  such  as  structure,  substructure ,  and  elements.  This  model  is 
schematically  shown  in  Figs.  3.4.1  and  3.4.2.  Another  example  of 
hierarchical  model  is  the  hypermatrix  data  organization.  Depending  on 
the  size  of  hypermatirx,  it  is  divided  into  number  of  submatrices  and 
arranged  at  various  hierarchical  levels.  In  design  optimization  also, 
the  data  related  to  design  variables  can  be  arranged  at  various 
hierarchical  levels.  For  example,  data  of  design  variable  number, 
design  group  link,  and  design  variable  values  can  be  arranged  at  various 
levels.  We  can  see  from  these  examples  that  hierarchical  model  fits 
naturally  with  the  usual  subdivision  of  design  data. 

3.4.2  Network  Data  Model 

In  network  data  model,  a  child  in  a  data  relationship  has  more  than 
one  parent.  A  network  is  more  general  than  a  hierarchy  because  a  given 
node  occurrence  may  have  any  number  of  immediate  superiors  as  well  as 


Figure  3.4.1.  Hierarchical  Data  Model 


Level  1 


Level  2 


Level  3 


Figure  3.4.2  An  Occurrence  of  a  Hierarchical  Data  Model 


any  number  of  immediate  dependents.  The  network  model  allows  many-to- 
many  relationships.  A  network  structure  is  said  to  be  simple  if  each 
directed  logical  association  is  functional  in  at  least  one  direction. 
This  means  the  model  has  no  line  which  has  double  arrows  in  both 
direction.  Complex  network  will  have  double  arrows  in  both 
directions.  Examples  of  network  model  for  a  finite  element  and  node 
relation  is  shown  in  Figs.  3.4.3  and  3.4.4. 

3.4.3  Relational  Model 

A  data  model  constructed  using  relations  is  referred  to  as  a 
relational  model.  A  relational  data  model  has  a  tabular  form  of  data 
representation .  Figure  3.4.5  represent  a  relational  model  of  data.  The 
rows  of  the  table  are  referred  to  as  tuples.  The  columns  are  referred 
to  as  attributes.  Relations  of  degree  (defined  in  Section  3.3)  one  are 
said  to  be  unary.  Similarly  relations  of  degree  two  are  binary, 
relations  of  degree  three  are  ternary,  and  relations  of  degree  n  are  n- 
ary.  The  relational  model  provides  an  easy  way  to  represent  data  and  is 
simpler  to  use  than  hierarchical  or  network  data  model.  The  relations 
can  I,-  easily  manipulated  using  special  relational  operators  such  as 
PROJECT,  JOIN,  etc.  The  operator  PROJECT  yields  a  'vertical'  subset  of 
a  given  relation,  i.e.,  subset  obtained  by  selecting  specified 
attributes.  The  operator  JOIN  puts  together  columns  from  different 
relations.  An  example  of  relational  model  in  finite  element  analysis  is 
node-coordinate  relation  snown  in  Fig.  3.4.5. 


3.4.4  Numerical  Model 


Most  of  the  computations  in  design  optimization  involve  operations 
on  matrices  like  matrix  addition,  multiplications,  solution  of 
simultaneous  equations,  and  eigenvalue  calculations.  The  data  models 
discussed  earlier  are  not  tailored  to  handle  matrix  data  effectively. 
It  is  necessary  to  provide  a  user-friendly  facility  for  defining  such 
numerical  data  and  manipulating  a  numerical  database.  It  is  possible  to 
provide  such  a  facility  by  defining  a  new  data  model  called  numerical 
model  (Sreekanta  Murthy,  Reddy,  Arora,  1984).  This  numerical  model  is 
basically  a  variation  of  hierarchical  data  model  having  two  levels  of 
data  representation.  At  the  first  level  information  pertaining  to  type 
and  size  of  data  is  placed.  The  second  level  contains  the  actual 
numerical  data.  This  model  is  shown  in  Fig.  3.4.6.  matrix  is 
referenced  through  a  user  defined  NAME  or  NUMBER.  Various  levels  of 
submatrix  organization  can  be  defined  through  parameter  called  LEVEL. 
TYPE  indicates  the  type  of  matrix:  square,  lower  triangular,  upper 
triangular,  banded  symmetric,  banded  nonsymmetric ,  diagonal,  etc.  ORDER 
indicates  user's  view  of  matrix  storage;  e.g.,  rows,  columns  or 
submatrices.  For  storage  or  retrieval  of  matrix  data,  the  unit  of 
transaction  will  be  in  terms  of  ORDER;  i.e.,  row,  column  or  full 
matrix.  Dimension  of  matrix  is  represented  by  the  number  of  ROWS  or 
COLUMNS.  PRECISION  parameter  specify  the  tolerance  required  while 
performing  floating  point  operations.  NULL  parameter  specifics  if 
matrix  is  null  or  not.  By  checking  this  parameter  unnecessary 
operations  on  null  matrices  can  be  eliminated,  thereby  saving 
considerable  storage  and  execution  time. 
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Examples  of  numerical  model  are  shown  in  Fig.  3.4.6.  Submatri: 


organization  for  level  1  is  shown  in  Fig.  3 .4 .6 ( i ) .  The  matri: 


information  for  level  0  can  be  described  in  the  same  way  as  shown  fc 


level  1.  Symmetric  banded  matrix  organization  is  shown  in  Fig, 


3.4.6(ii).  Note  that  rows  or  columns  are  of  variable  size.  Figure 


3.4.6(iii)  shows  an  upper  triangular  matrix  represented  in  the  model 


3.4.5  Choice  of  Data  Model  for  Structural  Design 


It  was  seen  that  various  types  of  data  models  described  in  the 


previous  sections  could  be  used  for  structural  analysis  and  design 


optimization  applications.  However,  it  is  not  possible  to  expect 


effective  use  of  any  one  of  the  models  in  all  situations.  Hierarchical 


data  model  is  clearly  superior  in  organizing  general  engineering  data 


which  occur  naturally  in  hierarchical  form.  For  example,  large  order 


matrices  can  be  assembled  using  submatrices.  These  submatrices  can  be 


organized  at  various  hierarchical  levels.  Network  model  handles  more 


general  situation  than  hierarchical  model.  The  disadvantage  of  this 


model  is  the  complexity  associated  with  its  use.  Both  hierarchical  and 


network  data  models  use  a  fixed  structure  and  offer  little  flexibility 


to  change  for  alternative  structure.  Another  drawback  of  the 


hierarchical  model  is  the  complexity  of  database  design  requiring 


tedious  process  of  establishing  links  between  data.  If  new  kinds  of 


data  are  to  be  added  or  new  information  must  be  generated  from  a 


database,  it  is  necessary  to  add  new  links.  Generally,  this  process 


requires  redesigning  the  entire  database.  However,  a  relational  data 
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mode]  uses  a  less  preconceived  structure  and  provides  user-friendly  data 
representation .  This  model  can  provide  easy  access  to  data  for  the 
user.  Also,  the  tabular  structure  of  the  model  provides  a  convenient 
way  of  representing  structural  design  data  that  are  generally  in  the 
tabular  form.  A  major  advantage  of  this  model  is  the  ease  with  which 
database  can  be  changed.  As  the  design  evolves,  new  attributes  and 
relations  can  be  added,  and  existing  ones  deleted  easily.  It  is 
possible  to  support  simple  query  structure  in  the  relational  model.  In 
situations  where  application  programs  require  a  complete  set  of  related 
items  together,  retrieving  parts  of  information  is  not  useful.  In  such 
a  case  the  relational  model  which  is  set  oriented  provides  a  suitable 
way  to  organize  the  design  data.  Numerical  model  appears  to  be  quite 
effective  in  representing  matrix  data  structure. 

Relational  and  numerical  data  models  are  therefore  selected  for 
detailed  study  for  design  of  the  database  and  the  development  of 
database  management  system  for  structural  analysis  and  optimization 
appl ications . 

3.5  Normalization  of  Data 

It  was  seen  in  the  previous  section  that  data  items  are  grouped 
■  g  j o c ' .  *  to  form  associations.  An  issue  of  concern  here,  is  how  to 
ec .  ;e  wnac  data  items  have  to  be  grouped  together?  In  particular, 
.iSiCj  o  relational  model,  determining  what  relations  are  needed  and  what 
lneT~  attrioutes  should  oe?  It  was  empnasized  in  Chapter  Z  that 
structural  design  data  gets  constantly  modified,  updated  and  deleted. 


As  database  is  changed,  older  views  of  data  must  be  preserved  so  as  to 
avoid  having  to  rewrite  the  programs  using  the  data.  However,  certain 
changes  in  data  associations  could  force  modification  of  programs,  and 
could  be  extremely  disruptive.  If  grouping  of  data  items  and  keys  is 
well  thought  out  originally,  such  disruptions  are  less  likely  to  occur. 

Normalization  theory  (Date  1982}  provides  certain  guidlines  to 
organize  data  items  together  to  form  relations.  The  theory  is  built 
around  the  concept  of  normal  forms.  A  relation  is  said  to  be  in  a 
particular  normal  form  if  it  satisfies  a  certain  specified  set  of 
constraints.  Three  normal  forms  -  1st,  2nd  and  3rd  -  are  described 
below. 

First  Normal  Form  (INF).  A  relation  is  said  to  be  in  first  normal 
form  if  and  only  if  it  satisfies  the  constraint  of  having  atomic  values. 

As  an  example.  Fig.  3.5.1  shows  the  relation  CONN  between  four 
attributes  ELMT#,  E-NAME,  NODES#,  and  DOF/NODE  with  domains  D1 ,  D£,  D3 
and  D4.  The  relation  is  first  shown  not  in  INF  and  then  it  is  shown  in 
the  INF. 

Second  Normal  Form  (2NF).  A  relation  is  in  the  second  normal  form 
if  and  only  if  it  is  in  INF  and  every  non-key  attribute  is  fully 
functionally  dependent  on  each  candidate  key. 

Let  us  see  if  the  relation  CONN  of  Fig.  3.5.1  in  the  INF  is  also  in 
2NF.  Consider  a  non-key  attribute  E-NAME: 

ELMT#,  NODES#  >  E-NAME 
ELMT#  >  E-NAME 


NODE#  A  E-NAME 
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Figure  3.5.1  First  Normal  Form  for  a  Relation  CONN 
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Therefore,  ELMT#,  NODES#  #>  E-NAME,  i.e.,  E-NAME  is  not  fully 
functionally  dependent  on  (ELMT#,  NODES#). 

Similarly  for  the  non-key  attribute  DOF/NODE: 

ELMT#,  NODES#  ♦  DOF/ NODE 
ELMT#  -►  DOF/  NODE 
NODE#  A  DOF/ NODE 

Therefore,  ELMT#,  NODES#  />  DOF/NODE.  Since  neither  E-NAME  nor  DOF/NODE 
are  fully  functionally  dependent  on  candidate  key  (ELMT#,  NODES#)  the 
relation  CONN  is  not  in  2NF. 

Conversion  of  the  relation  CONN  to  2NF  consist  of  replacing  CONN  by 
two  of  its  projections  (refer  to  Fig.  3.5.2). 

NAM-DOF  «•  CONN  (ELMT#,  E-NAME,  NODES#,  DOF/NODE) 
ELMT-NODE  <-  CONN  (ELMT#,  E-NAME,  NODES#,  DOF/NODE) 
Relation  ELMT-NODE  does  not  violate  2NF  because  its  attributes  are  all 
keys . 

Third  Normal  Form  (3NF).  A  relation  is  in  third  normal  form  if  it 
is  in  second  normal  form  and  every  non-prime  attribute  is  non- 
transitively  dependent  on  each  candidate  key  of  the  relation. 

For  example,  consider  the  relation  NAM-DOF  (Fig.  3.5.2)  to  see  if 
it  is  in  third  normal  form.  It  still  suffers  from  a  lack  of  mutual 
independence  among  its  non-key  attributes.  The  dependency  of  DOF/NODE 
on  ELMT#,  though  it  is  functional,  is  transitive  (via  E-NAME).  Each 
ELMT#  value  determines  an  E-NAME  value  and  in  turn  determines  the 
DOF/NODE  value.  This  relation  is  reduced  further  into  relations  NAME 
and  DOF.  These  relations  (Fig.  3.5.3)  are  in  third  normal  form. 


From  the  above  examples,  we  see  that  the  concept  of  normalization 
of  data  provides  a  good  basis  to  group  different  data  items  of 

structural  design.  Therefore,  the  concept  of  normal  forms  of  data  are 
used  in  this  study  to  develop  a  methodology  to  design  a  database  for 
structural  design.  Drawback  in  using  this  concept  is  that  its  use 
requires  a  rigorous  analysis  of  data  dependencies  and  their 

associations.  This  analysis  of  data  looks  complicated  at  this  stage  of 
research  on  database  management  for  structural  design  optimization. 

Also,  these  normal  forms  of  data  do  not  suggest  how  large  matrix  data 
should  be  organized  in  a  database.  However,  normalization  concept  is 
useful  in  organizing  general  data  used  in  finite  element  analysis  and 
de^'jn  optimization. 


3.6  Global  and  Local  Databases 

Computer-aided  design  of  complex  structural  systems  uses  several 
application  programs  during  the  design  process.  Many  of  these  programs 
require  common  information  such  as  geometry  of  the  structure,  finite 
element  idealization  details,  material  properties,  loading  conditions, 
structural  stiffness,  mass  and  load  distributions,  and  responses 
resulting  from  analysis  runs.  Also,  it  is  common  that  data  generated  by 
one  program  is  required  for  processing  in  subsequent  programs  in  certain 
predetermined  pattern.  These  data  do  not  include  transitory  information 
such  as  intermediate  results  generated  during  an  analysis  run.  The 


transitory  information  is  highly  unstructured  and  its  usage  pattern  is 
known  only  to  applications  that  use  them.  Generally,  the  transitory 


information  is  deleted  at  the  end  of  a  run.  Therefore,  there  is  a  need 
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for  systematic  grouping  of  the  data. 

A  network  of  databases  offers  a  systematic  approach  to  satisfy  the 
need  stated  above.  A  network  of  databases  consists  of  a  global  database 
connected  to  a  number  of  local  databases  through  program  data 
interface.  Application  programs  which  use  them  may  be  thought  as  links 
connecting  the  databases  (Fig.  3.6.1).  A  global  database  contains 
common  information  required  for  all  applications  whereas  a  local 
database  contains  only  application  dependent  transitory  data.  Data  in 
global  database  is  highly  structured  and  integrity  of  the  database  is 
maintained  carefully.  However,  data  in  local  database  is  extremely 
flexible  and  integrity  is  not  of  importance. 

This  network  of  databases  offers  considerable  aid  in  structural 
design  process.  Any  changes  made  to  the  data  in  global  database  is 

immediately  available  for  use  in  other  applications  of  the  system.  Any 

new  application  program  can  be  added  to  share  the  common  data.  The 
data  views  in  global  database  are  clear  to  all  applications  and  any 
modified  views  can  be  easily  incorporated  to  suit  a  new  application. 

Local  databases  are  dependent  on  application  programs  and  are  highly 
efficient  in  data  transfer  operations  since  no  overhead  is  involved  in 
maintaining  complicated  data  structures.  It  supports  trial  and  error 
design  process  by  providing  scratch  pad  work  space  which  can  be  erased 
f^om  the  local  database  at  a  specified  design  stage.  Any  intermediate 

results  can  be  stored  in  a  local  database.  Summarized  and  final  results 
of  design  can  be  transferred  to  a  global  database. 
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Figure  3.6.1  Network  of  Databases 


CHAPTER  4 


DATABASE  DESIGN  METHODOLOGY  FOR 
STRUCTURAL  ANALYSIS  AND  DESIGN 

4.1  Introductory  Remarks 

A  methodology  for  designing  databases  for  structural  design  is 
proposed  in  this  chapter.  The  methodology  is  based  on  the  database 
management  concepts  described  in  the  previous  chapter.  Background  for 
developing  the  database  design  methodology  is  given  in  Section  4.2.  In 
the  proposed  methodology  relational  and  numerical  data  models  are 
used.  Three  levels  of  data  organization  --  conceptual,  internal  and 
external  are  suggested  for  structural  design  database.  In  Section  4.3, 
a  methodology  for  constructing  a  conceptual  data  model  is  described. 
The  conceptual  model  enables  us  to  find  out  the  inherent  nature  of 
structural  design  data  irrespective  of  computer  program  constraints. 
Since  large  amount  of  data  storage  and  speed  of  accessing  data  are 
required  ir,  finite  element  analysis  and  optimi  zation ,  we  need  to 
consider  efficiency  of  storage  space  and  I/O.  This  aspect  is  considered 
in  Section  4.4.  A  methodology  for  developing  an  internal  model  is  given 
there.  In  Section  4.5,  a  methodology  for  developing  an  external  data 
model  is  described.  External  model  provides  data  needed  for  multiple 
users  or  application  programs  according  to  their  individual  perspectives 
nf  data.  Matrix  data  constitutes  a  large  portion  of  finite  element 
analysis  and  optimization  data.  Such  data  needs  special  considerations 
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for  accommodation  in  a  database.  A  methodology  for  organizing  large 
matrix  data  is  given  in  Section  4.6.  Finally  in  Section  4.7  algorithmic 
modelling  is  given.  Based  on  this  work,  a  paper  has  been  recently 
submitted  for  publication  (Sreekanta  Murthy  and  Arora,  1985b). 


4.2  Aspects  Considered  in  the  Proposed 
Methodology  and  Background 

Several  methodologies  for  designing  databases  for  business 
applications  have  been  researched  in  the  past  few  years.  However,  in 
engineering  database  management  area,  there  does  not  exist  any  rigorous 
study  on  design  of  a  database.  The  existing  finite  element  analysis  and 
design  optimization  programs  use  primitive  data  organization  techniques 
for  their  out-of-core  data  storage  needs.  The  drawbacks  of  such  schemes 
were  pointed  out  earlier. 

The  question  is  --  is  it  possible  to  develop  a  methodology  for 
designing  a  database  for  structural  analysis  and  design?  If  possible, 
how  do  we  begin  to  develop  a  methodology?  Are  the  methodologies  used  in 
business  application  suitable  for  our  purpose?  If  not,  what  aspects 
should  be  considered  in  developing  a  methodology  for  structural  design 
databases?  All  these  questions  have  to  be  considered  to  arrive  at  a 
methodology  for  database  design  needs. 

At  this  stage,  we  know  that  it  is  possible  to  identify  and  group 
the  data  used  in  finite  element  analysis  and  design  optimization.  We 
also  concluded  that  relational  and  numerical  data  models  are  suitable 
for  organizing  the  data.  The  basic  problem  is  that  once  all  the  data 
items  have  been  identified,  how  to  combine  them  to  form  useful 


relations.  In  business  applications  database  design  follows  some  well 
defined  steps.  First  step  is  the  extraction  of  all  the  characteristics 
of  the  information  which  is  to  be  represented  in  the  database.  Analysis 
of  the  information  and  their  integration  into  one  conceptual  model  is 
the  second  step.  The  conceptual  data  model  obtained  by  this  process  is 
abstract.  It  is  independent  of  any  computer  restraint  or  database 
management  software  support.  In  order  for  the  conceptual  model  to  be 
useful,  it  must  be  expressed  in  terms  compatible  with  a  particular  DBMS 
t j  considering  efficiency  of  storage  space  and  access  time.  An  internal 
model  is  developed  for  this  purpose  which  is  compatible  with  the 
conceptual  data  model.  Finally,  the  database  design  requires 

accommodation  of  different  users  of  the  database  by  providing  an 

external  data  model.  The  systematic  process  by  which  one  traverses  the 
different  steps  of  database  design  and  performs  the  mapping  from  one 

level  of  abstraction  to  the  next  is  called  a  database  design 
methodology. 

Suitability  of  some  of  the  methodologies  used  in  design  of 
databases  for  business  applications  to  design  databases  of  computer- 
aided  design  applications  has  been  investigated  by  Buchman  and  Dale 
(1979).  Tne  investigators  analyzed  three  existing  methodologies  -- 

Bubenxo's  methodology,  Kahn's  methodology,  and  Smith  and  Smith 


methodology  with  reference  to  applications  in  engineering  design  of  a 
chemical  plant.  A  list  of  criteria  for  evaluating  the  methodologies  is 
given.  Salient  characteristics  of  these  methodologies  are  outlined 
here.  In  Bubenko's  methodology,  entities  are  identified  and  classified 


from  query  and  transaction  descriptions.  A  strong  point  of  this  method 
is  the  provision  for  two  levels  of  abstractions.  Grouping  of  entities, 
however,  is  highly  intuitive  and  application  dependent.  Kahn’s  approach 
has  characteristics  of  separating  the  database  design  problem  into  two 
perspectives:  information  structure  perspective  which  describes  the 
interconnection  of  information,  and  the  usage  perspective  which  deals 
with  processing  requirement  of  information.  The  method  requires  design 
of  two  schema  -  one  processing  and  the  other  information  oriented  - 
which  are  merged  at  the  end  of  database  design  to  get  a  conceptual 
model.  This  methodology  merges  local  views  into  the  global  view  by 
aggregating  entities.  Designers  intuition  is  required  in  this 
methodology  to  form  nonredundant  entities  and  relations.  Smith's 
methodology  ignores  information  analysis  and  considers  only  abstract 
objects  of  interest.  An  object  can  be  viewed  as  entity,  attribute,  or 
relation  depending  solely  on  the  view  point  of  the  user.  The 
abstraction  step  used  in  this  method  is  highly  intuitive.  Grabowski  and 
Eigner  (1979)  pointed  out  the  necessacity  for  a  semantic  model 
construction  in  CAD  application.  They  described  three  available 
semantic  models  using  the  example  of  a  geometric  model  of  a  line:  (i) 
based  on  binary  association,  (ii)  based  on  entity  and  attribute 
association,  and  ( i  i  i )  expanded  relational  model. 

The  methodologies  described  above  are  at  the  research  state  in 
busir  s  data  management  field  and  are  not  suitable  for  engineering 
applications.  Also  many  of  them  do  not  discuss  details  of  the  procedure 
or  implementation  aspect  and  hence  cannot  be  directly  used  for  designing 


an  engineering  database.  Therefore,  it  is  necessary  to  adopt  good 
features  and  guidelines  provided  by  existing  methodologies  and  arrive  at 
a  suitable  one  to  design  databases  for  finite  element  analysis  and 
structural  design  optimization  applications. 

The  proposed  methodology  to  design  databases  (Sreekanta  Murthy  and 
Arora,  1985b)  considers  several  features  and  requirements  of  finite 
element  analysis  and  structural  design  optimization  applications.  Some 
important  features  of  data  considered  in  the  methodology  are  --  tabular 
structure,  matrices,  static  information,  operational  information, 
multiple  views  of  data  for  different  application,  and  iterative  changes 
in  data.  Tabular  structure  of  data  is  organized  using  relational  data 
model,  whereas  large  matrix  data  needs  is  organized  using  a  numerical 
data  model.  A  simpler  approach  to  design  a  database  is  by  considering 
static  and  operational  information  seperately  for  an  initial  design  and 
later  merging  them  to  arrive  at  a  final  design.  Multiple  views  of  data 
necessary  to  accommodate  theoritical,  implementational  and  user's 
requirements  are  considered.  Conceptual,  internal  and  external  views  of 
data  suggested  by  ANSI/SPARC  is  considered  to  accommodate  multiple  views 
of  data.  The  methodology  uses  entity  set,  relationship  set  and 
attributes  to  form  syntactic  basic  elements  of  the  conceptual  model. 

In  summary  the  methodology  developed  here  considers  the  following 
aspects:  (i)  Three  views  of  data  --  conceptual,  internal,  and  external 
as  suggested  by  ANSI/SPARC;  (ii)  Entity  set,  relationship  set,  and 
attributes  to  form  syntactic  basic  elements  of  the  conceptual  model; 
(iii)  Relational  data  model;  (iv)  Matrix  data;  (v)  Processing 
requirements;  and  (vi)  Normalization  of  data  for-  relational  model. 


4.3  Methodology  to  Develop  a 
Conceptual  Data  Model 


4.3.1  Basic  Considerations 

Our  objective  now  is  to  develop  a  methdology  to  form  a  conceptual 
data  model  at  a  suitable  level  of  abstraction  regardless  of  whether  or 
not  the  available  database  management  software  supports  such  model 
directly.  The  conceptual  data  model  should  serve  as  a  central  reference 
point  for  all  applications  using  the  database.  It  changes  only  if 
changes  in  the  structural  design  process  occur.  Any  change  in  the 
database  management  software  of  application  program  should  not  affect 
the  conceptual  data  model.  The  model  should  be  capable  of  supporting 
new  applications  with  the  existing  types  of  data  as  well  as 
incorporating  further  data  types  as  needed.  Therefore,  an  analysis  of 
data  used  in  structural  design  is  required  to  incorporate  the  features 
of  data  model  described  above.  In  the  analysis,  the  information  in  use 
or  needed  in  future  is  identified,  classified  and  documented.  This 
forms  a  basis  for  the  conceptual  data  model  to  represent  structural 
design  data  and  design  process  as  a  whole. 

Two  basic  approaches  are  proposed  to  develop  a  methodology  to  form 
a  conceptual  data  model.  One  approach  considers  the  general  data  of 
finite  element  analysis  and  design  optimization  such  as  geometry, 
material  properties,  element  connectivity,  element  level  vectors  arid 
matrices.  A  conceptual  model  is  developed  for  these  types  of  data. 
Since  large  matrices  such  as  assembled  stiffness,  load,  and  mass 
matrices  have  basically  different  characteristics  a  separate  approach  is 
proposed  in  the  later  sections  of  this  chapter  to  construct  a  conceptual 


data  model .  The  two  approaches  together  form  a  methodology  to  develop  a 
conceptual  data  model  for  both  types  of  data  used  in  finite  element 
analysis  and  design  optimization. 

The  following  steps  are  proposed  to  develop  a  conceptual  data  model 
for  general  data.  These  steps  are  discussed  in  detail  in  Subsections 
4.3.2  to  4.3.5. 


Step  1.  Identify  all  the  characteri sti cs  of  data  used  in 
structural  analysis  and  design  optimization. 


Step  2.  Data  identified  are  stored  in  a  number  of  relations.  They 
are  reduced  to  elementary  relation  which  represent  inherent  association 
of  data. 


Step  3.  More  elementary  relations  are  derived  from  the  ones  formed 
in  Step  2.  This  step  uncovers  more  relationships  between  basic  data 
collected  in  Step  2. 


Step  4.  Redundant  and  meaningless  relations  obtained  in  Step  3  are 
removed  to  obtain  conceptual  data  model. 

The  conceptual  model  obtained  by  this  process  is  abstract  and  is  of 
theoretical  interest  representing  inherent  nature  of  structural  design 
data  and  is  independent  of  any  computer  restraint  or  database  management 
software  support. 


4.3.2  Identification  of  Conceptual  Data  Objects 

The  following  steps  are  proposed  to  ioentify  the  conceptual  data 
objects  used  in  structural  design: 
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Step  1.  Identify  each  type  of  entity  and  assign  a  unique  name  to 
it. 

Step  2.  Determine  the  domains  and  assign  unique  names  to  them. 
This  step  identifies  the  information  which  will  appear  in  the  model, 
such  as  attributes. 

Step  3.  Identify  the  primary  key  for  each  type  of  entity  depending 
on  the  meaning  and  use. 

Step  4.  Replace  each  entity  set  by  its  primary  key  domains. 
Determine  and  name  relations  corresponding  to  association  between 
primary  key  domain  and  other  domains.  Also,  include  relations 
corresponding  to  association  between  entities  themselves.  This  step 
gives  a  collection  of  relations  forming  a  rough  conceptual  data  model. 

Modified  definition  of  domain  and  attribute  are  suggested  as 
follows  to  suit  correct  identification  of  structural  design  information. 

Domain.  A  domain  is  the  set  of  eligible  values  for  a  property.  A 
domain  has  same  characteristics  as  a  set,  i.e.,  the  values  belonging  to 
a  domain  are  distinct  and  their  order  is  immaterial.  A  domain  can 
contain  vectors  or  matrices.  Thus  domain  is  defined  as 

Di  ■ 

where  represents  a  value,  a  vector,  or  a  matrix  satisfying  the 


Attribute.  Columns  of  a  two-dimensional  table  are  referred  to  as 


attributes.  An  attribute  value  can  contain  relation  names  and  null 
val  ues . 

Example.  We  consider  the  sample  structural  design  problem  given  in 
Section  2.2,  to  describe  these  steps. 

Step  1.  The  following  entity  sets  are  identified  for  the  structure: 
STRUCTURE  (S) 

BEAM  (B) 

TRUSS  (T) 

MEMBRANE-TRI  (TR) 

MEMBRANE-QD  (QD) 

NODE  (N) 

ELEMENT  (E) 

Step  2.  We  identify  the  following  domains: 

STRUCTURE#  Structure  identification  number  (integer) 

B#  Beam  element  identification  number  (integer) 

T #  Truss  element  identification  number 

( integer) 

TR#  Triangular  membrane  element  identification 

number  (integer) 

QD#  Quadri 1 ateral  membrane  element 

identification  number  (integer) 

NODE#  Node  number  (integer) 

E#  Element  number  (integer) 


EL-TYPE 


Element  type  { BEM2 ,  BEM3,  TRS2,  TRS3,  TRM2 
TRM3,  QDM2,  QDM3 }  (character) 


!  MATID 

i 

l 

i 

* 

MATPRO 

1 

|  CSID 

i 

i 


CSPRO 

DOF# 

LOAD-TYP 

X 

Y 

Z 

DESCRIPTION 

VEC 


Material  identification  code,  e.y., 
(STEEL - 1 ,  STEEL*2,  ALUM*5,  COMP.l}.  It 

also  refers  to  relation  or  table  of 
material  properties;  for  example,  STEEL*1 
refers  to  relation  STEEL  and  material 
subtype  1  (character) 

Material  property  {E,u,G,...}  (real) 
Cross-section  type  identification  code; 
e.g.,  THICK»1,  THICK*2,  RECT*1,  CIRC*5, 
ISEC*6,  LSEC-15} .  It  also  refers  to  a 
relation  of  cross-sectional  details.  For 
example,  RECT*1,  refers  to  a  relation  RECT 
and  cross-section  subtype  1  (character) 
Cross-sectional  property  {H,W,T,R, . . . } 
(real ) 

Degrees  of  freedom  numbers  (integer) 

Load  type  (CONCENTRATED,  DISTRIBUTED, 
TEMPERATURE,  ACCELERATION}  (characters) 

X  coordinate  (real ) 

Y  coordinate  ( real ) 

Z  coordinate  (real ) 

Description  (characters) 

Vectors  (Integer,  Real  and  Double  precision 
vectors}  (vector) 
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VECID 


MAXID 


Matrices  {Integer,  Real  and  Double 
precision  matrices}  (matrices) 

Vecto  identification  code  (character) 
=  {x-yj  x  =  vector  description,  y  = 
number};  e.g.,  FORCE-5,  LOAD-10 
Matrix  identification  code  (character) 
=  }x-y|  x  =  matrix  description,  y  = 

number};  e.g.,  EL-STIFF- 10,  EL-MASS-5 


Step  3.  The  following  entity  keys  are  identified 
STRUCTURE#  for  entity  set  structure 

BEAM#  for  entity  set  beam 

TRUSS#  for  entity  set  truss 

TR#  for  entity  set  TR 

QD#  for  entity  set  QD 

E#  for  entity  set  element 


Step  4.  In  the  association  between  entity  sets  and  domain,  the 
entity  sets  from  Step  1  are  replaced  by  their  primary  keys.  Attribute 
names  are  derived  from  domain  names  to  provide  role  identification.  The 
following  relations  are  identified: 

For  Entity  Set  STRUCTURE 

STRUCTURE  ( S# ,  DESCRIPTION,  MAXID,  MATX) 

The  structure  is  identified  by  a  structure  number  S#.  Name  of  the 
structure  and  other  details  are  given  in  DESCRIPTION.  Matrices 
associated  with  the  structure  are  identified  by  MAXID. 

For  Entity  Set  BEAM 
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BEAM  (B#,  E#,  EL-TYP,  MATID,  E,  u,  G,  N0DE1#,  N0DE2#,  CSID, 

H,  W,  LOAD-TYP,  LOAD#,  VECID,  VEC,  MAX  ID,  MATX) 

A  beam  is  identified  by  a  beam  number  B#.  Element  number  E#  uniquely 
identifies  the  finite  elements  of  a  structure.  Attributes  NODE1#  and 
N0DE2#  are  derived  from  domain  of  node  numbers.  Similarly,  E,  4,  and  G 
are  role  names  for  domain  of  material  property  values.  CSID  identifies 
the  cross-section  properties  H,  and  W.  Vectors  and  matrices  associated 
with  the  element  are  identified  through  VECID  and  MAXID,  respectively. 
Similarly  the  relations  TRUSS,  TRM,  and  QDM  are  as  follows: 
TRUSS  (T#,  E#,  EL-TYPE,  MATID,  E,  N0DE1#,  N0DE2#,  CSID,  H,  W 
LOAD-TYP,  LOAD#,  VECID,  VEC,  MAXID,  MATX) 

TRM  (TR#,  E#,  EL-TYPE,  MATID,  E,  N0DE1#,  N0DE2#,  N0DE3#, 

CSID,  T,  LOAD-TYP,  LOAD#,  VECID,  VEC,  MAXID,  MATX) 

QDM  (QD#,  E#,  EL-TYP,  MATID,  E,  NODE  1# ,  N0DE2#,  NODE3#, 
N0DE4#,  CSID,  T,  LOAD-TYP,  LOAD#,  VECID,  VEC,  MAXID, 

MATX) 

NODE  (NODE#,  X,  Y,  Z,  D0F1#,  D0F2#,  D0F3#,  LOAD-TYP,  LOAD#, 
VICID,  VEC) 

ELEMENT  (E#,  NODE#) 

From  the  above  example,  the  following  points  unique  to  structural 
design  databases  should  be  noted: 

1.  The  attributes  in  the  example  contain  relation  names  (e.g.,  MATID, 
CSID).  These  relations  are  again  association  between  an  entity 
set;  e.g.,  STEEL  and  domain  of  material  properties. 


2. 


Null  values  of  domains  (which  are  attributes  in  the  relations)  are 
allowed.  For  example,  in  relation  TRM,  LOAD-TYP  and  LOAD#  may  be 
nul 1  i f  no  loads  exi sts . 

3.  A  row  and  a  column  intersection  may  not  be  a  single  value;  it  can 
be  a  vector  or  a  matrix. 

4.3.3  Reduction  to  Elementary  Relations 

In  the  previous  section,  we  described  a  method  to  identify 
entities,  domains  and  relations  to  produce  a  rough  conceptual  model  of 
data  used  in  finite  element  analysis  and  design  optimization.  Our  idea 
is  to  develop  a  conceptual  model  which  contains  all  the  facts  and  each 
fact  occurring  only  once.  For  this  purpose,  we  suggest  the  use  of 
concept  of  elementary  relations  (Vetter  and  Maddison,  1981)  to  transform 
the  rough  conceptual  data  model  into  a  better  model. 

A  relation  is  irreducible  if  it  cannot  be  broken  down  by  means  of 
project  operations  into  several  relations  of  smaller  degree  such  that 
these  relations  can  be  joined  to  reconstitute  the  original  relation.  A 
relation  which  is  not  reducible  is  called  an  elementary  relation. 

To  see  how  elementary  relations  satisfy  the  requirement  that  one 
fact  is  recorded  in  one  place,  an  example  is  given  below: 

LOAD  (N#,  LC#,  Fx) 
wnere  N#  is  node  number 

LC#  is  load  case  number 

Fx  is  force  in  the  x-direction 


Note  that  this  relation  describes  two  facts--load  cases,  and  load 
values  for  each  node.  Now,  to  see  if  this  is  an  elementary  relation, 
suppose  we  split  the  relation  LOAD  by  means  of  project  operations  into 
following  two  relations  R1  and  R2: 


R1(N#,  LC#) 


R2(LC#,  F„) 


N# 

LC# 

N1 

LI 

N1 

L2 

N1 

L3 

N2 

L2 

N2 

L3 

N2 

L4 

N3 

L3 

LC# 

Fx 

LI 

10.0 

L2 

15.0 

L2 

20.0 

L3 

10.0 

L3 

20.0 

L4 

10.0 

On  joining  R1  and  R2,  R1*R2  we  get 
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N# 

LC# 

Fx 

N1 

LI 

10.0 

N1 

L2 

15.0 

*  N1 

L2 

20.0  <- 

N1 

L3 

10.0 

>  N1 

L3 

20.0 

+  N2 

L2 

15.0 

N2 

L3 

10.0 

+  N2 

L3 

20.0 

N2 

L4 

10.0 

>  N3 

L3 

10.0 

N3 

L3 

20.0 

<N1,L2>  and  <L2,20.0> 


The  rows  marked  with  +  are  not  in  the  original  relation  LOAD  and  hence 
not  correct.  Thus,  the  relation  is  irreducible,  and  it  is  an  elementary 
relation.  Observe  that  in  the  relation  LOAD  the  attribute  Fx  is  fully 
functionally  dependent  on  N#  and  LC#.  N#  alone  or  LC#  alone  does  not 
determine  Fx.  Therefore,  it  is  possible  to  identify  such  dependencies 
and  establish  rules  for  reducing  a  relation  to  an  elementary  relation. 
Using  the  concept  of  functional  dependencies,  full  functional 
dependencies,  and  transitive  dependencies,  the  following  steps  are 
identified  to  form  elementary  relations: 

Step  1.  Replace  the  original  relations  by  other  new  relations  to 
eliminate  any  (nonfull)  functional  dependencies  on  candidate  keys. 

Step  2.  Replace  the  relations  obtained  in  Step  1  by  other 
relations  to  eliminate  any  transitive  dependencies  on  candidate  keys. 
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Step  3.  Go  to  Step  5  if 

(a)  relation  obtained  is  all  keys,  and 

(b)  relation  contains  a  single  attribute  that  is  fully  functionally 
dependent  on  a  single  candidate  key. 

Step  4.  Determine  primary  key  for  each  relation  which  may  be  a 
single  or  composite  attribute.  Take  projections  of  these  relations  such 
that  each  one  contains  a  primary  and  a  non-primary  key. 

Step  5.  Elementary  relations  obtained. 

Example.  We  can  see  how  these  steps  are  applicable  to  relations  of 
the  example  problem  in  the  previous  section.  Consider  the  relation  TRM: 

TRM  (TR#,  E#,  EL-TYPE,  MATID,  E,  N0DE1#,  N0DE2#,  N0DE3#,  CSID,  T, 
LOAD-TYP,  LOAD#,  VECID,  VEC,  MAX  I D ,  MATX) 


Dependencies 


Remarks 


TR#  Primary  key 

TR#  >  E#  also  E#  -*•  TR#  Secondary  key  E# 

TR#  +  EL-TYPE  Element  type  is  functionally  dependent 

on  TR# 

TR#  +  MATID  Material  identification  code  MATID  is 

functionally  dependent  on  TR# 

MATID  +  E  Material  properly  E  is  functionally 

dependent  on  MATID 

TR#  *  MATID  ♦  E  Material  property  E  is  transitively 

dependent  on  TR#  through  MATID 
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TR#  identifies  N0DE1# 


TR#  *  N0DE1# 

TR #  >  N0DE2# 

TR#  +  NODE3# 

TR#  +  CS-TYP  +  T  Thickness  is  transitively  dependent 

on  TR#  through  CS-TYP 

TR#  +  LOAD-TYP 

TR#  ♦  LOAD# 

TR#  >  VECID  *  VEC  Any  vectors,  such  as  load,  force, 

stress  vector  are  transitively 
dependent  on  TR#  via  VECID 

TR#  ♦  MAX  ID  ->■  MATX  Similarly  matrices  such  as  stiffness, 

mass,  are  transitively  dependent  on  TR# 
via  MAXID 

Reducing  relation  TRM  to  elementary  relations 

Step  1. 

ER1  (TR#,  E#) 

ER2  (TR#,  EL-TYP) 

ER3  (TR#,  NODE  1 # ) 

ER4  (TR#,  N0DE2# ) 

ER5  (TR#,  NODE3*) 

ERi4  (E#,  T.’#) 


ER6  (TR#,  MAT  ID);  ER7  (MATID,  E) 

ER8  (TR#,  CSID) ;  ER9  (CSID,  T) 

ER10  (TR#,  VECID);  ER11  (VECIO,  VEC) 

ER12  (TR#,  MAX  ID) ;  ER13  (MAX  ID,  MATX ) 

Step.  3  The  above  relations  contain  single  attribute,  so  go  to 
Step  5. 

Step.  4.  Skip 

Step  5.  ER1  to  ER13  are  elementary  relations. 

These  steps  are  used  on  the  rest  of  the  relations  identified 
earlier  to  get  a  set  of  elementary  relations  for  the  sample  structural 
problem. 

4.3.4  Determination  of  Transitive  Closure 

We  generally  obtain  hundreds  of  elementary  relations  when  the  steps 
given  above  are  applied  to  actual  finite  element  analysis  and  design 
optimization  data.  While  deriving  a  large  number  of  relations  for 
obtaining  a  conceptual  data  model,  it  is  possible  that  some  relations 
might  have  been  missed.  In  general,  it  is  possible  to  derive  further 
elementary  relations  from  any  incomplete  collection  of  such  relations. 
To  explain  in  a  simple  way,  how  such  additional  relations  can  be 
derived,  consider  two  relations  ER1(A,B)  and  ER2 ( B , C) ,  which  imply 
functional  dependencies:  A  ->•  8  and  B  C.  We  know  that  product  of 
functional  dependencies  leads  to  transitive  dependencies  (Vetter  and 
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Maddison,  1981).  Taking  product  of  above  functional  dependencies,  we 
yet  A  ►  C.  Therefore,  from  suitable  pairs  of  elementary  relations 
representing  functional  dependencies  further  elementary  relations  can  be 
derived.  Deriving  all  such  relations  from  initial  collection  of 
elementary  relations  yields  a  transitively  closed  collection  of 
elementary  relations  called  transitive  closure  (Vetter  and  Maddison, 
1981).  This  set  of  relations  includes  both  derived  and  original 
elementary  relations.  It  is  complete  in  the  sense  that  all  elementary 
relations  equivalent  to  transitive  dependencies  through  others  are 
included.  There  is  always  a  unique  transitive  closure  for  a  given  set 
of  elementary  relations.  A  transitive  closure  usually  contains  many 
redundant  relations.  We  say  that  an  elementary  relation  is  redundant  if 
it  is  derivable  from  other  relations. 

There  are  problems  associated  in  interpreting  relations  in 
transitive  closure.  For  example,  consider  relations  ER1  (TR#,  MATID) 
where  TR*  ►  MATID  and  ER7  (MATID,  E)  where  MATID  ■>  E.  Transitive 
closure  for  this  set  yields  relation  ER  (TR#,  E)  implies  TR#  identifies 
E.  Tnis  relation  does  not,  however,  represent  true  information  as 
material  property  E  is  dependent  only  on  material  number  and  not  on 
e'emmc  numoer.  The  relation  could  be  wrongly  interpreted.  Therefore 
such  semantically  meaningless  dependencies  must  be  eliminated. 

It  is  possible  to  determine  transitive  closure  using  directed 
graphs  ano  tne  connectivity  matrix  (defined  in  Section  3.2).  The  nodes 
of  .j-apr.  correspond  to  entity  Keys  and  arcs  correspond  to  elementary 
rel ati oos . 


Transitive  closure  is  formed  by  adding  arc  3  if  arcs  1  and  2  already 
exist.  A  diagraph  for  the  elementary  relations  formed  in  the  previous 
section  is  shown  in  Fig.  4.3.1. 

A  connectivity  matrix  for  this  diagraph  is  shown  in  Fig.  4.3.2.  In 
the  connectivity  matrix,  we  can  see  for  example,  TR#  >  MATID  is 
indicated  by  1  in  the  corresponding  row(3)  and  column(7)  of  the 
matrix.  Derived  transitive  dependence  of  example  TR#  >  E  is  recorded  by 
assigning  1  to  C  (3,11).  Such  derived  relations  are  denoted  by  1*  in 
the  Fig.  4.3.2  and  are  denoted  by  new  arcs  in  dotted  lines  of  Fig. 
4.3.1.  An  algorithm  for  determining  transitive  closure  is  given  in 
Appendix  I. 

The  transitive  closure  for  the  example  produces  additional 
dependencies  given  in  Table  4.3.1.  We  have  eliminated  meaningless 
dependencies  from  the  list. 

4.3.5  Selecting  Elementary  Relations  to 
Form  a  Conceptual  Data  Model 

In  the  previous  section,  we  derived  additional  elementary  relations 
from  a  set  of  original  elementary  relations  of  Section  4.3.3.  Now,  we 
have  all  the  data  items  and  their  associations  in  terms  of  a  large 
number  of  elementary  relations.  We  will  see  that  many  relations  are 
redundant  and  therefore  they  should  be  removed  to  provide  a  minimal  set 
of  elementary  relations. 


Figure  4.3.1 
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Figure  4.3.2  Connectivity  Matrix  C  for  Elementary  Data 
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Table  4.3.1  Transitive  Closure  for  Elementary  Relations 


Derived  Semantically 

Relations  Dependencies  Composi tionMeani nyful 


E#  ♦  EL-TYP 

E#  +  TR# 

* 

EL-TYP 

E#  *  N0DE1# 

E#  >  TR# 

* 

N0DE1# 

E#  >  N0DE2# 

E#  *  TR# 

-► 

N0DE2# 

E#  *  N0DE3# 

E#  ♦  TR# 

> 

N0DE3# 

E#  >  MATID 

E#  >  TR# 

* 

MATID 

£#  *  CS ID 

E#  >  TR# 

> 

CSID 

E#  >  LOAD-TYP 

E#  +  TR# 

> 

LOAD-TYP 

E#  >  MAX  ID 

E#  ►  TR# 

MAX  ID 

TR#  >  E 

TR#  +  MAX  ID  +  E 

TR#  >  T 

TR#  +  CS- 

-TYP  +  T 

TR#  *  VEC 

TR#  >  VECID  ■>  VEC 

TR#  MATX 

TR#  >  MATX ID  ►  MATX 

life 


One  method  of  removing  redundant  elementary  relations  is  by  finding 


a  minimal  cover  (Vetter  and  Haddison,  1981).  A  minimal  cover  is  a 
smallest  set  of  elementary  relations  from  which  transitive  closure  can 
be  derived.  This  method  removes  redundant  relations  by  eliminating 
elementary  relations  which  are  composition  of  other  elementary 
relations.  The  composition  having  maximum  distance  (defined  in  Section 
3.3)  is  removed  first  and  process  is  repeated  iteratively  to  obtain  a 
minimal  cover.  This  method  is  illustrated  in  Fig.  4.3.3  and  Table 

4.3.2.  However,  the  method  is  too  tedius  to  use  in  practical  situations 
where  hundreds  of  elementary  relations  are  formed. 

We  suggest  an  alternate  methodology  to  select  the  elementary 
relations  to  form  the  conceptual  data  model.  Information  about 

processing  sequence  of  data  in  finite  element  analysis  and  design 
optimization  data  should  be  used  for  eliminating  redundant  elementary 
relations.  For  example,  consider  the  set  of  transitive  closure  of  Fig. 

4.3.3.  E#  in  the  example  uniquely  identifies  all  elements  used  in  a 

structure,  whereas  TR#  identifies  only  the  element  numbers  in  a 

triangular  membrane  element  group.  For  example,  to  compute  element 

stiffness  matrix  data,  two  processing  sequences  are  possible.  One 
processing  sequence  computes  stiffness  for  all  types  of  elements  using 
E#.  In  this  case,  selection  of  relations  ER1,  ER19,  and  ER7  is  more 
appropriate  because  material  data  is  obtained  in  minimum  number  of 
accesses.  On  the  other  hand,  if  stiffness  computation  is  carried  out 
seperately  for  each  type  of  element  (for  example  TR#),  then  alternate 

choice  of  elementary  relations  ER1,  ER6,  ER7  is  suitable.  Thus,  in 


selecting  a  set  of  elementary  relations  to  form  a  conceptual  model  of 
data,  a  certain  amount  of  judgement  is  necessary  on  the  part  of  database 
designer.  By  considering  the  processing  sequence  of  data  while  removing 
redundant  elementary  relations  will  considerably  reduce  effort  required 
to  form  a  final  set  of  elementary  relations  representing  a  conceptual 
da"a  model  for  finite  element  analysis  and  design  optimization  data. 


4.4  Methodology  to  Design  an  Internal  Model 

Once  we  have  a  conceptual  (theoretical )  data  model  of  finite 
element  analysis  and  design  optimization  data,  the  next  step  is  to 
design  an  internal  model.  Internal  model  shows  how  the  data  should  be 
actually  stored  in  a  database  using  a  database  management  software.  An 
internal  model  specifies  which  attributes  have  to  be  combined  together 
as  a  unit  forming  relations  that  are  actually  stored  in  a  database. 

In  this  section,  a  methodology  to  design  an  internal  model  is 
proposed.  The  methodology  is  based  on  two  important  aspects:  (i) 

normalization  of  data,  and  (ii)  processing  requirement  of  data.  Three 
normal  forms  of  relations,  i.e.,  1st,  2nd  and  3rd  normal  forms  are  used 
to  arrange  attributes  selected  from  various  domains.  It  is  known  that 
the  use  of  normal  forms  of  relations  helps  in  avoiding  inconsistency  in 
data  storage  and  update  operations  (Date,  1977).  The  second  aspect  of 
the  methodology  suggests  the  use  of  processing  requirement  of  finite 
element  analysis  and  design  optimization  data.  The  processing  needs  of 
analysis  and  design  specify  how  various  attributes  should  be  derived 
from  their  underlying  domains  and  combined  together  forming  a  n-ary 
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relation.  Therefore,  it  is  necessary  to  identify  all  the  processes  used 
in  finite  element  analysis  and  design  optimization  computations. 

After  an  internal  model  is  developed,  it  should  be  verified  for 
consistency  with  the  conceptual  model.  Also,  efficiency  aspect  of  the 
model  should  be  considered  in  the  design.  This  aspect  requires 
modification  of  the  internal  model  to  reduce  the  number  of  accesses  to 
get  the  data.  Finally,  the  internal  model  developed  should  be 
accommodated  with  a  particular  database  management  system  that  will 
actually  be  used  to  store  and  retrieve  data.  All  these  aspects  of  the 
methodology  to  design  an  internal  data  are  discussed  in  the  following 
paragraphs  with  the  help  of  an  example. 

Design  of  an  internal  model  to  support  element  stiffness  matrix 
generation  process  is  described  here.  Methodology  for  designing 
internal  models  for  other  structural  analysis  and  design  process  would 
follow  similar  steps.  We  assume  that  a  conceptual  model  for  element 
stiffness  generation  is  already  available.  Our  aim  is  to  produce  an 
internal  model  that  is  consistent  with  the  conceptual  model  given  by  the 


following  elementary  relations 
ER1  (TR# ,  EL-TYP) 

ER2  (TR#,  NODE  1 # ) 

ER3  (TR#,  N0DE2#) 

ER4  (TR#,  N0DE3# ) 

ER5  (TR#,  MATID) 

ER6  (MATID,  E) 

ER7  (TR#,  CSID) 

ER8  (CSID,  T) 


ER9  (NODE#,  X) 

ER10  (NODE#,  Y) 

ER11  (NODE#,  Z) 

ER12  (TR#,  MATXID) 
ER13  (MATXID,  MATX) 
ER14  (E#,  NODE#) 
ER15  (TR#,  E#) 
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Data  needed  for  generation  of  element  stiffness  matrix  are  derived 
from  various  domains  and  represented  in  a  single  relation  TRM-D  as  shown 
in  Fig.  4.4.1.  Our  main  intention  is  to  get  all  the  data  required  for 
generation  of  stiffness  matrix  for  a  triangular  membrane  element  in  one 
access  or  minimum  number  of  accesses. 

Observe  from  the  relation  of  Fig.  4.4.1  that  it  is  not  in  the  first 
normal  form.  Therefore,  this  unnormalized  relation  should  be  replaced 
by  a  semantically  equivalent  relation  in  INF  as  shown  in  Fig.  4.4.2. 

The  following  points  have  to  be  noted  for  normalization  procedure 
in  structural  design  context: 

1.  Row  and  column  intersection  of  a  relation  in  INF  is  atomic  (i.e., 
consists  of  single  values).  Exception  to  these  rules  are  vectors 
and  matrices  and  they  are  considered  to  be  atomic.  In  Figure 
4.4.2,  a  set  of  values  of  MATX  is  identified  as  a  unit. 

2.  Values  for  attributes  are  also  derived  from  a  non-simple  domain.  A 
non-simple  domain  is  one  which  contains  elements  that  themselves 
are  relations.  In  Figure  4.4.2,  STEEL  refers  to  another  relation 
which  contain  material  properties. 

The  advantage  of  INF  over  the  unnormalized  relation  are  that 
operations  required  for  application  programs  are  less  complicated  and 
easy  to  understand. 

The  elementary  relations  identified  earlier  contain  all  the 
information  required  for  generation  of  element  stiffness  matrices.  This 
information  should  be  reflected  in  some  way  in  the  internal  model  that 
is  to  be  developed.  There  by  we  can  ensure  that  internal  model  is 
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Figure  4.4.1  A  Tentative  Internal  Model 


IR#  E#  El-TYP  MATIO 


CSIO  T  NODE #  X  j  Y  /  MAIXII)  f 


1  15  TRM3  STEEL-5  I08  TIHCK-8  0.1  5  1.  5.  7.  SII -1 

1  15  TRM3  STEEL-5  108  THICK-8  0.1  7  3.  4.  8.  SIE-1 

1  15  TRM3  STEEL-5  108  THICK-8  0.1  8  2.  6.  3.  STF - 1 

2  16  TRM3  ALUM-4  0.9xl07  THICK-4  0.2  12  5.  9.  8.  STE-2 

2  16  TRM3  ALUM-4  0.9xl07  THICK-4  0.2  14  7.  4.  1.  STE-2 

2  16  TRM3  ALUM-4  0.9xl07  THICK-4  0.2  18  3.  5.  8.  SIT -2 


Figure  4.4.2  Relation  TRM-D  in  INF 
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consistent  with  the  conceptual  model.  Internal  model  of  Fig.  4.4.2  has 
all  the  attributes  providing  information  for  generation  of  element 
stiffness  matrix.  To  check  the  consistency  of  this  model,  first  we 
identify  the  key  attributes.  Candidate  keys  are  compound,  consisting  of 
(E#,  NODE#)  and  (TR#,  NODE#).  Primary  key  is  selected  as  (TR#, 
NODE#).  Secondary  keys  are  TR#,  E #,  MATID,  CSID,  NODE#,  and  MATXID. 
These  key  attributes  of  the  relation  are  consistent  with  those  in  the 
elementary  relation.  Secondly,  we  need  to  identify  whether  all  the 
attributes  in  internal  model  and  dependencies  between  them  are 
consistent  with  the  conceptual  model.  Observe  that  attributes  N0DE1#, 
N0DE2#  and  N0DE3#  do  not  appear  in  the  relation.  Therefore,  these  three 
attributes  should  be  included  in  the  relation.  Relation  TRM-D  is  now 
written  as 

TRM-D  (TR#,  E#,  EL-TYP,  E,  CSID,  T,  NODES#,  N0DE1#,  NODE 2#, 
N0DE3#,  X,  Y,  X,  MATXID,  MATX) 

The  functional  dependencies  reflected  by  elementary  relations  ER1  to 
ER15  are  satisfied  in  the  internal  model  with  the  values  shown  in  the 
Fig.  4.4.2.  Therefore,  at  this  instant  the  internal  model  is  consistent 
with  the  conceptual  model.  However,  it  would  be  no  longer  consistent, 
if  arbitrary  changes  in  the  values  of  the  table  are  made.  Also,  note 
that  many  values  in  the  relation  TRM-D  are  redundant.  These 
inconsistencies  and  redundancies  occur  because  of  the  following 


anomalies  in  the  INF: 


1. 


INSERT  operations:  User  cannot  store  details  concerning  a  finite 
element  without  knowing  at  least  one  node  of  the  element.  The 
reason  is  that  one  part  of  the  primary  key  (E#,N0DE #),  i.e,  NODE# 
is  not  known. 

2.  DELETE  operations:  If  user  deletes  a  particular  material  type  - 
MATID,  the  database  automatically  looses  all  the  data  about  those 
finite  elements  using  the  material.  Similarly,  if  user  deletes  a 
particular  finite  element,  then  database  looses  data  about  a 
particul ar  material . 

3.  MODIFY  operations:  To  change  information  about  a  particular 

element  number,  all  rows  containing  that  element  number  have  to  be 
modified.  Otherwise  functional  dependency  MATID  E  will  not  be 
val id  any  more. 

Therefore  it  is  not  desirable  to  use  the  relation  in  Fig.  4.4.2  to 
represent  the  internal  model.  Modification  of  this  relation  to  2NF  is 
necessary  to  avoid  these  anomalies  in  the  storage  operations.  For  this 
purpose,  first  we  need  to  identify  non-key  attributes  of  TRM-D  and  check 
their  dependence  on  the  candidate  keys.  The  non-key  attributes  are  EL- 
TYP,  E,  T,  X,  Y,  Z,  MATX  (refer  to  definition  of  full  functional 
dependency).  For  example,  consider  the  non-key  attribute  EL-TYP: 

E#,  NODE#  >  EL-TYP 
E#  +  EL-TYP 
NODE#  A  EL-TYP 


Therefore , 


E#,  NODE#  #>  EL-TYP 


Thus,  EL-TYP  is  not  fully  functionally  dependent  on  (E#,N0DE#).  Note 
that  E  is  transitively  dependent  on  E#  through  MATID.  Similar  argument 


leads  to 


E*,  NODE**  #>  E,  T,  X,  Y,  Z  or  MATX . 


Therefore,  relation  TRM-D  should  be  converted  into  a  set  of 
semantically  equivalent  relations  as  follows: 

TRM-DI  (TR# ,  E#,  EL-TYPE,  NODE 1 # ,  N0DE2#,  N0DE3#, 

MATID,  E,  CSID,  T,  MATX ID,  MATX) 

TRM-D2  (NODE#,  X,  Y,  Z) 

TRM-D3  (E#,  NODE#) 

The  above  three  relations  TRM-DI,  TRM-D2  and  TRM-D3  are  all  in  2NF 

because  first  two  relations  do  not  possess  any  compound  candidate  key 

and  third  relation  has  all  keys.  Note  that  by  splitting  the  relation, 
TRM-D  no  information  is  lost  and  they  still  are  consistent  with  the 

conceptual  model.  However  TRM-DI  relation  is  still  not  satisfactory  as 
it  can  lead  to  anomolies  in  storage  operations  as  follows: 

1.  INSERT  operation:  It  is  not  possible  to  store  the  fact  that  a 

particular  material  -  MATID  has  a  property  -  E  without  knowing  at 

least  one  finite  element  using  the  material. 

2.  DELETE  operation:  If  only  one  element  is  using  a  particular 

material  and  if  that  element  is  deleted,  we  loose  all  information 

aDOut  the  material . 

3.  MODIFY  operation;  If  several  finite  element  use  a  particular 

material  and  if  the  property  of  the  material  is  changed,  then 
modification  must  be  done  to  all  the  rows  of  the  material  used  by 
those  elements. 


Therefore  it  is  not  feasible  to  use  TRM-D1  relation  in  the  internal 
model.  Modification  of  this  relation  is  necessary  to  3NF  to  avoid 
anomalies  in  storage  operation.  Non-key  attributes  must  be  non- 
transitively  dependent  on  candidate  keys  to  avoid  these  anomolies. 
Observe  from  the  relation  TRM-D1  of  Fig.  4.4.3  that  attributes  E,  T,  and 
MATX  are  transitively  dependent  on  TR#  through  MAUD,  CSID,  and  MATXID, 
respecti vely .  Removing  these  transitive  dependencies,  we  get  the 
following  relation: 

TRM-D4  (TR#,  E# ,  EL-TYP,  N0DE1#,  N0DE2#,  NODE 3#,  MATID, 

CSID,  MATXID) 

TRM-D5  (MATID,  E) 

TRM-D6  (CSID,  T) 

TRM-D7  (MATXID,  MATX) 

The  above  four  relations  together  with  TRM-D2  and  TRM-D3  constitute 
the  internal  model  for  element  stiffness  matrix  generation  purpose. 
This  internal  model  is  consistent  with  the  conceptual  model  identified 
earlier.  Also,  note  that  number  of  relations  in  the  internal  model  is 
only  6  as  compared  to  15  elementary  relations  in  the  conceptual  model. 

In  summary,  the  following  steps  are  necessary  to  derive  an  internal 
model  that  is  consistent  with  the  conceptual  model.  Normalization 
procedures  have  to  be  adopted  at  each  step  to  reduce  redundancy  and  to 
eliminate  undesired  anomolies  in  storage  operation.  At  each  step 
unsatisfactory  relations  are  replaced  by  others. 


Step  1.  Form  relations  with  attributes  derived  from  a  set  of 
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Figure  4.4.3  Relations  in  ZNF 
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Step  2.  Eliminate  multiple  values  at  row-column  intersection  of 
relation  table.  Vectors  and  matrices  are  considered  to  be  single 
data  items  for  this  step. 

Step  3.  Result  of  Step  2  is  the  relations  in  the  INF.  Take 


projections  of  INF  relations  to  eliminate  any  nonfull  functional 
dependencies  and  get  relations  in  the  2NF. 

Step  4.  Take  projection  of  relations  obtained  in  Step  3  to 
eliminate  transitive  dependencies  to  form  relations  in  the  3NF. 
Thus  a  set  of  relations  in  the  3NF  is  the  internal  model. 

The  next  question  in  the  design  of  internal  model  is  the 
efficiency.  Is  the  internal  model  obtained  by  considering  normalization 
process  an  efficient  one  to  use?  This  question  posed  in  another  way  -- 


is  it  possible  to  get  the  data  required  for  a  particular  process  in  a 
minimum  number  of  accesses  to  the  database?  If  not,  how  to  reduce  the 
number  of  accesses  to  get  the  data.  The  answer  to  these  questions  is 


obtained  by  a  study  of  the  individual  processes  and  their  data 
requirement  needs. 

Again,  consider  the  previous  example  of  internal  model  consisting 


of  relations  TRM-D2,  TRM-D3,  TRM-D4,  TRM-D5,  TRM-D6  and  TRM-D7 .  To 
access  the  thickness  data  T  of  a  particular  element  TR#,  one  has  to 
first  access  the  CSID  data  from  TRM-D4,  then  retrieve  TRM-D6  relation  to 


get  the  required  data.  Thus  two  database  accesses  are  required. 
Similarly,  to  get  the  coordinates  of  an  element  TR#,  first  the  node 
numbers  of  the  elements  have  to  be  identified,  then  from  relation  TRM-D2 
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coordinates  of  nodes  are  retrieved.  In  this  case,  four  database 
accesses  are  required  including  three  accesses  to  relation  TRM-D2.  One 
possibility  of  reducing  the  number  of  accesses  to  the  database  is  by 
combining  relations  TRM-D4,  TRM-D2  and  TRM-D5.  Such  combination 
increases  efficiency  at  the  expense  of  redundancy  in  data  storage  and 
anomolies  in  storage  operations. 

Therefore,  it  is  suggested  to  use  normal  forms  of  relations  for  the 
internal  model  and  introduce  redundancy  if  required  to  improve 
efficiency  at  the  actual  impelmentation  stage.  But  such  redundant  and 
unnormalized  relations  should  be  carefully  noted  to  avoid  erroneous 
operations  on  database. 

4.5  Some  Aspects  to  Accommodate 
an  External  Model' 

One  of  the  important  requirements  of  a  database  is  to  provide 
facility  for  data  retrieval  by  different  application  programs  depending 
on  their  needs.  Different  application  programmers  can  have  different 
views  of  a  database.  Data  structure  as  seen  by  an  application  program 
or  interactive  user  is  called  an  external  data  model.  Generally,  user's 
perspective  of  a  database  is  only  a  subset  of  the  actual  contents  of  the 
database.  Data  retrieved  from  actual  physical  storage  in  the  database 
undergoes  transformation  till  it  reaches  the  user.  Transformation 
involves  rearrangement  of  data  from  internal  level  to  external  level 
into  a  form  acceptable  to  the  application  program.  In  the  following 
paragraphs,  considerations  required  while  designing  an  external  model 
suitable  to  structural  design  applications  are  given. 


Some  constraints  have  to  be  observed  while  designing  an  external 


model.  Constraints  arise  while  rearranging  data  from  internal  data 
structure  to  an  external  data  structure.  An  important  constraint  is 
that  internal  data  structure  must  be  consistent  with  the  conceptual  data 
structure.  Any  retrieval  and  storage  operations  specified  on  external 
model  must  be  correctly  transformed  into  corresponding  operations  on  the 
internal  model  and  at  the  same  time  data  must  be  consistent  with  the 
conceptual  data  model.  Also  design  of  the  external  model  must  fit  the 
database  management  system  capability.  An  example  of  how  an  external 
model  is  derived  from  an  internal  model  is  given  below. 

Suppose  a  particular  user  would  like  to  know  the  coordinates  of 
nodes  of  each  triangular  finite  element  for  generation  of  element 
stiffness  matrices.  This  means  that  the  external  model: 

EL-CORD  (TR#,  E#,  EL-TYPE,  XI,  Yl,  Zl,  X2,  Y2,  Z2,  X3,  Y3,  Z3) 
has  to  be  provided  for  that  particular  user.  Note  that  the  external 
view  EL-CORD  contains  data  items  from  two  different  relations  --  TRM-D4, 
TRM-D2  (refer  Section  4.4).  Therefore,  a  procedure  is  required  to 
transform  internal  data  model  (relations  TRM-D4,  TRM-D2)  to  the  external 
data  model  (relation  EL-CORD).  Data  from  TRM-D4  and  TRM-D2  have  to  be 
rearranged  to  obtain  relation  EL-CORD.  Procedure  for  rearrangement  is 
formulated  by  using  JOIN  and  PROJECT  operations  as  follows: 

TRM-A  (TR#,  E#,  EL-TYP,  N0DE1#)  «-  TRM-D4 

TRM-B  (TR#,  E#,  EL-TYP,  N0DE2#)  «•  TRM-D4 

TRM-C  (TR#,  E#,  EL-TYP,  N0DE3#)  «-  TRM-D4 

TRM-D  (TR#,  E#,  EL-TYP,  XI,  Yl,  Zl)  =  TRM-A*TRM-D2 


»  rx*  "w  -  »  ■  *  * 


TRM-E  ( TR# ,  £#,  EL-TYP,  X2,  Y2,  Z2)  =  TRM-B*TRM-D2 
TRM-F  (TR#,  E#,  EL-TYP,  X3,  Y3,  Z3)  =  TRM-C*TRM-D2 
EL-CORO  (TR#,  E#,  EL-TYP,  XI,  Yl,  Zl,  X2,  Y2,  Z2, 


X3,  Y3,  13)  =  TRM-D*TRM-E*TRM-F 
NOTE:  «-  indicates  PROJECT;  *  indicates  JOIN 

The  above  procedure  (algorithm)  yields  EL-CORD  relation.  Observe 
from  the  algorithm  that  we  did  not  modify  the  original  relations  TRM-D4 
and  TRM-D2  to  retrieve  the  data  required  for  a  particular  inquiry.  The 
relations  TRM-D4  and  TRM-D2  are  still  consistent  with  the  conceptual 

model.  Therefore,  pure  retrieval  operations  for  rearrangement  of  data 
does  not  cause  any  inconsistency  in  data  values. 

Now,  consider  the  reverse  process  of  transforming  external  data 
structure  to  internal  data  structure.  Suppose,  a  particular  user  wants 
to  insert  the  nodal  coordinates  of  a  finite  element  using  the  external 
view  EL-CORD.  Here,  relation  EL-CORD  has  the  only  key  TR#  and  has  no 
reference  to  tne  node  number  to  which  the  element  is  connected. 
Insertion  is  not  consistent  with  the  conceptual  model  which  requires 

that  coordinate  of  nodes  which  are  dependent  on  keys  NODE#.  This 
restriction  is  also  reflected  in  the  internal  model  --  TRM-D2  which 
requires  NODE#  as  key  values  for  insertion.  Therefore,  the 
transformation  of  relation  EL-CORD  into  internal  model  is  not 

possible.  From  this  example,  it  follows  that  there  are  restrictions  for 

rearranging  data  from  external  model  to  internal  model. 


4.6  Methodology  to  Incorporate  Large  Matrix 


ata  into  a  Database 

In  finite  element  analysis  and  structural  design  optimization,  we 
encounter  problem  of  storage  of  large  order  matrices.  These  matrices 
are  generally  banded  and  sparse,  and  require  careful  consideration  in 
organizing  them  in  databases.  This  special  nature  of  matrix  data  is 
unique  to  structural  design  database  and  therefore  no  attempts  have  been 
made  to  study  this  aspect  in  business  database  management  area. 
However,  a  few  matrix  schemes  have  been  implemented  on  disk  files,  but 
they  are  highly  tailored  to  meet  only  specific  application  program  needs 
and  not  suitable  for  general  use.  Consequently,  there  is  a  need  for  the 
development  of  a  generalized  and  a  new  user-friendly  technique  to  deal 
with  large  order  matrices.  In  this  section,  we  discuss  various  types  of 
large  order  matrices  and  develop  a  suitable  methodology  for  organizing 
them  in  a  database. 


4.6.1  Identification  of  Matrices 


Various  types  of  matrices  are  identified  and  defined  below.  Note 
that  matrices  considered  for  our  purpose  are  of  large  order  which 
implies  a  matrix  A(m,n)  where  m  and  n  about  1000  or  more.  For  the 
purpose  of  our  discussion,  matrices  are  grouped  into  five  types  and  are 
referred  by  the  type  number. 


Square  Matrix  A 

A  h  a(i,j)  i  =  1,  2,  .. .  n,  j  =  1 ,  . . .  m 
A  square  matrix  A  is  symmetric  i f  A  =  A^ 
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A  square  matrix  A  is  diagonal  if 
a(i  ,j)  *  0  for  i  =  j 

a ( i ,  j  )  =  0  for  i  *  j 

A  square  matrix  A  is  upper  triangular  if 
a(i ,j )  *  0  for  i  <  j 

a(  i  ,j )  =  0  for  i  >  j 

A  square  matrix  A  is  lower  triangular  if 
a(i  ,j )  *  0  for  i  >  j 

a(i  ,j)  =  0  for  i  <  j 

(ii)  Banded  Matrix  A 

a(i  ,j)  =  0  for  ji-j  |  >  m 

where  m  <<  n;  n  =  matrix  size 
a(  i  ,j )  *  0  for  |i-j  |  <  m 

Consider  =  1  +  (j-1)  for  all  i,  where  j  is  the  column  number 
for  last  nonzero  entry  in  row  i,  then  semi-band  width  B  =  max 
b.j  (refer  to  Fig.  4.6.1) . 

(iii)  Hypermatrix  H 

H  =  h(k,£)  k  =  1,  ...  p,  i  =  1,  ...  p 
where  h( k , L)  h  square  nonnull  matrix  A  for  some,  k,£ 

^  square  null  matrix  A  for  some  k,t 
and  A  =  a(i,j)  i  =  1,  ...m,  j  =  1,  ...m 

A  is  known  as  submatrix  of  H.  k  and  I  are  known  as  hyper-rows 
and  hyper-columns  (refer  to  Fig.  4.6.2). 

H  is  upper  triangular  if 


h(  k ,  l)  =  A  for  k  <  I 


=  0  for  k  >  i 


H  is  lower  triangular  if 


h(k,t)  =  A  for  k  >  A 


=  0  for  k  <  i 


(iv)  Sky-line  Matrix  S 


For  symmetric  upper  triangular  matrix 


S  2  a ( i , k )  i  =  1,  ...  n,  k  =  1,  ...  n 


rrij  =  row  number  of  first  nonzero  element  in  column  j;  mj 


j  =  1,  ...  m  define  the  skyline. 


( j -m j )  =  column  height 

a ( i  ,k )  =  0  for  k  >  (j-mj);  (refer  to  Fig.  4.6.3) 


Sparse  Matrix  P 


P  =  a( i  ,j )  i  =  1,  ...  m,  j  =  1,  ...  n 


P  is  sparse  if 


a ( i , j )  =  0  for  most  values  of  i  and  j.  As  a  rule  of  thumb. 


only  about  5  to  20%  of  the  matrix  contains 


nonzero  values  at  scattered  locations  in  the 


sparse  matrix. 


4.6.2  Methodology  for  Design  of  a  Numerical  Model 


We  identified  various  types  of  matrices  commonly  encountered  in 


finite  element  analysis  and  design  optimization  procedures.  It  is 


necessary  to  establish  a  methodology  for  organizing  these  matrices  in  a 


.v  <»  •• . 

v  '/Jy  'v.v.vjv.  •» Sy. -%v. 


s-  S 


’  «*v  A  aV’-’.V / 


database.  A  numerical  model  is  proposed  in  this  section  which  consists 
of  conceptual,  internal  and  external  views  of  large  matrices.  Recall 
that  a  conceptual  view  represent  inherent  nature  of  data  independent  of 
any  computer  constraints.  Therefore  it  is  necessary  to  first  study  true 
nature  of  a  large  order  matrix.  Later,  the  internal  representation  of  a 
matrix  are  considered  to  deal  with  storage  efficiency,  processing 
sequence,  matrix  operations,  and  flexibility  of  data  modi f ication . 
Since  different  applications  and  users  view  the  same  matrix  in  different 
form,  suitable  external  views  have  to  be  provided. 

Conceptually,  a  matrix  is  a  two-dimensional  array  of  numbers. 
These  numbers  appear  in  a  certain  pattern;  e.g.,  square,  sparse, 
symmetric  diagonal  ,  banded,  lower  triangular  form,  upper  triangular 
form,  unitary  form,  tridiagonal  form,  hyper  matrix  form  and  skyline 
form.  A  matrix  is  uniquely  identified  by  a  name.  Rows  and  columns  of 
the  two-dimensional  array  are  used  for  identification  of  data  elements 
in  the  matrix.  A  conceptual  view  of  a  matrix  is  represented  by  the 
following  elementary  relations: 


ER1  (NAME,  MATRIX  TYPE) 

ER2  (NAME,  NUM-OF-ROWS) 

ER3  (NAME,  NUM-OF-COLUMNS) 

ER4  (NAME,  ROW,  COLUMN,  DATA-ELEMENT-VALUE ) 

ER5  (NAME,  NUM-OF-HYPER  ROWS) 

ER6  (NAME,  NUM-OF-HYPER  COLUMNS) 

ER7  (NAME,  HYP-ROW,  HYP-COLUMN,  ROW,  COLUMN,  DATA-ELEM-VALUE ) 
ER8  (NAME,  BAND-WIDTH) 


ER 10  (  NAME,  SUB-MAT-ROW-SIZE) 

ER11  (NAME,  SUB-MAT-COLUMN-SIZE) 

ERI2  (NAME,  VECTOR  OF  SKYLINE-HEIGHT) 

ER 13  (NAME,  HYP-ROW,  HYP-COLUMN,  NULL-OR-NOT) 

The  attributes  of  these  elementary  relations  are  self  descriptive. 
These  elementary  relations  completely  define  a  matrix  and  provide  the 
conceptual  structure  of  the  matrix.  Note  that  the  data  values  assigned 
to  a  matrix  do  not  depend  on  whether  a  matrix  is  in  banded,  skyline  or 
hyper  matrix  form.  But  they  are  located  using  on  the  row  and  column 
number  of  a  matrix.  Therefore,  additional  information  such  as  banded, 
skyline,  hyper  matrix,  bandwidth,  and  submatrix  size  are  useful  mainly 
to  take  advantage  of  the  special  nature  of  a  matrix  for  storage  and 
computational  purpose. 

Internal  (storage)  structure  for  large  order  matrices  have  to  be 
developed  which  is  consistent  with  the  conceptual  structure.  The 

el  omen t ary  reiations  defined  above  could  be  stored  in  a  database,  but  it 
would  require  an  awful  number  of  accesses  to  get  the  required  matrix 
data.  Therefore,  storage  schemes  have  to  be  developed  based  on 

efficiency  considerations.  Also,  storage  space  consideration  is 

important  to  save  disk  space.  Special  nature  of  matrix,  i.e.,  is 
sparse,  dense,  symmetric,  should  be  used  to  provide  storage 

efficiency.  We  can  classify  various  matrix  types  considered  in  the 
previous  section  into  two  basic  types  -  sparse  and  dense.  Note  that 
bandec  or  diagonal  matrices  are  not  to  be  mistaken  as  sparse.  Many 

possible  storage  schemes  are  availaole  to  store  dense  and  sparse 
matrices.  First,  we  consider  storage  of  large  order  dense  matrices. 


Conventional  storage  schemes  --  row-wise,  column-wise,  submatrix- 
wise  are  useful  for  storing  dense  matrices.  Row  and  column  storage  are 
considered  to  be  similar  for  purpose  of  our  discussion.  Thus,  out  of 
these  storage  schemes,  only  two  schemes  --  row-wise  and  submatrix  wise 
are  considered  for  evaluation.  Figure  4.6.4  shows  the  row  and  submatrix 
storage  schemes.  Again,  it  is  stressed  here  that  we  are  considering  the 
internal  storage  schemes  and  not  the  users  view  of  a  matrix  -  such  as 
row-wise,  column-wise,  submatrix  wise,  skyline  wise,  or  upper- 
triangular.  Choice  between  these  two  storage  schemes  should  be  based  on 
consideration  of  several  aspects  -  storage  space,  processing  sequence, 
matrix  operation,  page  size,  flexibility  for  data  modification,  ease  of 
transformation  to  other  storage  schemes  or  user's  views,  number  of 
addresses  required  to  locate  rows  or  submatrices,  and  availability  of 
database  management  system  support.  These  aspects  are  considered  in 
detail  below. 

Storage  Space.  Row  storage  scheme  can  be  used  for  square,  banded 
and  skyline  matrix  types.  However,  this  scheme  is  not  appropriate  for 
hypermatrix.  Symmetric,  triangular,  and  diagonal  properties  of  square 
matrix  can  be  used  in  saving  storage  space  if  variable  length  of  rows  is 
used.  Similar  schemes  can  be  used  for  banded  and  skyline  matrices  to 
store  data  elements  that  appear  in  a  band  or  skyline  column.  Submatrix 
storage  can  be  used  for  all  matrix  types.  Submatrix  storage  is  most 
appropriate  for  hypermatrix  data.  Both  schemes  have  di sadvantages  when 
zero  elements  within  a  row  or  submatrix  ha.e  to  be  stored. 
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Processing  Sequence.  Row  storage  requires  assembly  of  matrices, 
storage  and  retrieval  be  made  only  row-wise.  This  becomes  inefficient 
if  row-wise  processing  cannot  be  made.  Submatrix  approach  is  suitable 
for  all  types  of  processing  sequence  --  row-wise,  column-wise,  or  in  any 
arbitrary  order. 

Matrix  Operations.  Operations  such  as  transpose,  addition, 
multiplications  and  solutions  of  simultaneous  equations  are  frequently 
carried  out  at  various  stages  of  structural  design.  Row  storage  scheme 
is  highly  inefficient  for  matrix  transpose  when  column-wise  storage  is 
required.  During  mul ti pi ication  of  two  matrices  A  and  B,  a  column  of  B 
can  only  be  obtained  only  by  retrieving  all  of  rows  of  B.  Therefore, 
row  storage  scheme  become  inappropriate  for  such  operation.  However, 
submatrix  storage  scheme  does  not  impose  any  such  constraints  in  matrix 
operation,  thus  provides  a  suitable  internal  storage  scheme. 

Page  Size.  A  page  is  a  unit  or  block  of  data  stored  or  retrieved 
from  memory  to  disk.  A  more  detailed  definition  will  be  given  in  the 
next  chapter.  For  a  fixed  page  size,  only  a  number  of  full  rows  or  a 
number  of  full  submatrices  together  with  fractional  parts  of  them  can  be 
stored  or  retrieved  at  a  time.  It  is  clear  that  fragmentation  of  rows 
or  submatrices  takes  place  depending  upon  the  size  of  rows  or 
submatrices.  Large  row  size  will  overlap  more  than  one  page  in  memory 
and  cause  wastage  of  space.  Submatrix  scheme  has  the  advantage  of 
providing  flexibility  in  choosing  submatrix  size  to  minimize 
fragmentation  of  pages. 


Flexibility  for  Data  Modification.  For  modifications  of  rows  of  a 
matrix  both  row  and  submatrix  storage  schemes  are  suitable.  But  row 
scheme  would  be  more  efficient  than  submatrix  storage  scheme.  For 
modifications  of  a  few  columns  of  a  matrix,  row  storage  scheme  requires 
a  large  number  of  I/O. 

Transformation  to  Other  Schemes.  Submatrix  storage  scheme  requires 
minimum  number  of  data  access  to  transform  to  column-wise  storage 
scheme . 

Address  Required.  Submatrix  storage  requires  less  number  of 
addresses  to  locate  data  than  row  storage  scheme  provided  submatrices 
are  reasonably  large. 

Thus,  for  internal  storage  of  large  order  matrices  in  a  database, 
the  above  mentioned  aspects  should  be  carefully  considered.  It  appears 
that  both  submatrix  and  row  storage  schemes  can  be  appropriate  for 
various  applications. 

In  order  that  internal  storage  scheme  be  consistent  with  the 
conceptual  model,  we  need  to  store  additional  information  about  the 
properties  of  the  matrix.  Those  additional  informations  are  given  by 
the  elementary  relations  ER1,  ER2,  ER3,  ER5,  ER6,  ER9  to  ER13.  They  can 
be  combined  together  and  stored  in  a  relation  with  key  attribute  NAME. 
Relations  required  for  internal  storage  are  indicated  in  Fig.  4.6.5. 

So  far  we  considered  schemes  for  internal  organization  of  large 


matrices.  Since  different  users  view  the  same  matrix  in  different  forms 
-  banded,  skyline,  hypermatrix,  triangular,  or  diagonal  -  it  is 
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necessary  to  provide  the  external  views  to  suit  individual  needs.  Unit 
of  transactions  on  various  views  of  a  matrix  may  be  row-wise,  column¬ 
wise,  submatrix-wi se  or  data  element  wise.  Internal  scheme  is 
submatrix-wise,  where  as  external  view  need  not  be  submatrix  wise. 
Therefore,  transformation  are  necessary  to  convert  the  internal  matrix 
data  into  the  form  required  for  a  particular  user.  Such  a 
transformation  is  schematically  indicated  in  the  Fig.  4.6.6. 

Next,  we  consider  sparse  matrix  storage  scheme.  Several  storage 
schemes  have  been  suggested  by  Pooch  (1973)  and  Daini  (1982).  They  are 
bit-map  scheme,  address  map  scheme,  row-column  scheme,  and  threaded  list 
scheme.  Out  of  these  row-column  scheme  is  simple  and  easy  to  use. 
Also,  row-column  scheme  can  be  easily  incorporated  into  relational 
model.  Therefore,  this  scheme  can  be  considered  for  storing  sparse 
matrices  encountered  in  design  sensitivity  analysis. 

Row-column  storage  scheme  consists  of  identification  of  row  and 
column  numbers  of  nonzero  elements  of  a  sparse  matrix  and  storing  them 
in  a  table.  This  scheme  provides  flexibility  in  modification  of  data. 
Any  nonzero  value  generated  during  a  course  of  matrix  operation  can  be 
stored  or  deleted  by  simply  adding  or  deleting  a  row  in  the  stored 
taDle.  The  row-column  scheme  is  schematically  shown  in  Fig.  4.6.7. 

External  view  of  row-column  storage  scheme  can  be  provided  through 
suitable  transformation  procedures.  An  external  view  of  this  scheme  is 
shown  in  Fig.  4.6.8. 


bViV'V 


•  Y-V??: 

y/'  k 

v'  •/  <  ! 

\» 


r 


EXTERNAL  VIEW 


EXTERNAL  VIEW 
B 


EXTERNAL  VIEW 

_  C 


internal  storage  scheme 
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Figure  4.6.7  Row-Column  Storage  Scheme  (Internal) 
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4.7  An  Algorithw  or  A  Data  Model? 

So  far  we  considered  various  methods  and  procedures  for  data 
organization,  wherein,  actual  storage  of  data  in  a  database  was 
necessary.  Many  procedures  in  structural  design,  such  as  element 

stiffness  matrix  routines,  generate  huge  amounts  of  data.  Generally,  it 
is  unlikely  that  a  user  would  want  them  to  be  stored  in  a  database  at 
the  expense  of  disk  space  and  data  transportation  time.  The  advantage 
of  being  able  to  query  or  possibly  modify  individual  data  items  does  not 
apply  to  stiffness  matrices,  which  are  more  or  less  meaningless,  except 
to  the  analysis  program  for  which  each  matrix  nas  been  assembled.  In 
order  to  save  disk  space  and  data  transfer  time,  it  is  preferable  to 
store  only  those  data  that  are  required  for  generation  of  element 

stiffness  matrix.  An  algorithmic  model  is  one  where  a  data  model  is 
replaced  by  (i)  an  algorithm  that  generates  the  user  requested 

information  and  (ii)  a  set  of  (condensed)  data  which  will  be  used  by  the 
algorithm  to  generate  the  user  requested  information.  Therefore,  in  an 
algorithmic  model,  data  are  not  stored  but  are  generated  whenever  they 
are  needed.  Algorithmic  model  suggested  with  a  mixture  of  algorithms 
and  stored  data  in  a  way  that  is  most  efficient  for  any  given 

appl ication . 

Study  of  resource  aspects  must  be  made  for  deciding  suitability  of 
an  algorithmic  model  or  a  data  model.  In  cases  where  the  items  being 
modeled  is  rich  in  empirically  derived  data  (for  example,  steel  codes 
for  allowable  stress  calculations)  the  algorithmic  model  uses  a  simple 
algorithm  with  a  conventional  data  model.  At  the  other  extreme,  where 
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all  properties  of  an  item  can  be  generated  (for  example,  element 
stiffness  matrix  calculations)  the  algorithmic  model  uses  a  complex 
algorithm  with  minimum  data.  A  data  model  is  preferable  when  storage 
capacity,  processing  costs,  usage  rates  are  high  and  time  to  transport 
data,  rate  of  change  of  data  are  low.  An  algorithmic  model  is  better  if 
storage  capacity,  processing  costs,  usage  rate  of  data  are  low  and 
transport  cost  are  high. 

Methodology  for  constructing  an  algorithmic  model  is  proposed  based 
on  (i)  design  of  a  suitable  algorithm,  and  (ii)  design  of  a  (condensed) 
data  model.  Design  of  algorithms  is  dependent  on  the  standard  method  of 
computational  techniques  used  in  finite  element  analysis  and  design 
optimization.  These  algorithms  must  be  acceptable  to  all  users  of  the 
model.  Data  transfer  between  algorithm  and  (condensed)  data  model  can 
be  provided  through  database  management  system  support.  Interface 
between  algorithmic  model  and  applications  must  be  designed  based  on 
consideration  of  simplicity  and  ease  of  use.  Design  of  (condensed)  data 
model  is  dependent  on  the  algorithm  itself.  If  the  condensed  data  model 
uses  a  conventional  data  model,  then  schemes  for  ensuring  correctness  of 
data  values  in  the  model  must  be  provided.  This  is  necessary  because  if 
this  condensed  data  model  is  allowed  to  be  modified  arbitrarily  then 
resulting  data  generated  by  algorithms  will  become  meaningless.  If 
several  algorithms  are  in  operation  each  using  only  a  portion  of 
condensed  data  model,  then  decomposition  of  the  data  model  into  several 


low  level  forms  will  enable  efficient  access  of  data  values. 


CHAPTER  5 


DATABASE  MANAGEMENT  SYSTEM  FOR 
STRUCTURAL  DESIGN  -  A  PROPOSAL 

5.1  Introductory  Remarks 

We  need  a  software  to  use  a  database  that  has  been  designed  based 
on  the  methodology  given  in  the  previous  chapter.  A  software  that 
handles  requests  of  users  to  access  and  store  data  in  a  form  compatible 
with  data  organized  at  various  levels  between  physical  storage  level  and 
application  program  level  is  called  a  database  management  system.  A 
database  management  system  conceals  the  complex  data  storage  details  and 
provide  a  simple  view  of  database  to  the  users.  Such  a  software  enables 
structural  design  application  programmers  and  interactive  users  to  store 
and  retrieve  required  data  in  a  simple  way  and  thereby  relieving  them  of 
unnecessary  burdon  of  managing  physical  storage  details. 

This  chapter  is  intended  to  identify  various  components  of  a  DBMS 
and  to  formulate  requirements  of  data  definition,  data  manipulation  and 
query  language  in  view  of  implementation  of  a  good  DBMS  for  structural 
design  optimization.  A  DBMS  should  have  many  components  such  as  command 
processor,  input-output  processor,  file  operation  routines,  addressing 
and  searching  schemes,  and  memory  management  schemes  in  order  to  provide 
simple  and  efficient  means  of  data  storage  and  retrieval.  Functions  and 
requirements  of  these  components  are  described  in  Section  5.2  with 
reference  to  structural  design  applications.  In  Sections  5.3  to  5.5 


a  proposal  of  syntactic  rules  (grammer)  for  languages  used  by 
structural  designer  to  define  data  view,  manipulate  data  and  query  data 


are  yiven.  Data  definition,  data  manipulation  and  query  language 
requirements  are  formulated.  Finally  in  Section  5.6,  existing  database 
management  systems  are  reviewed  and  their  features  tabulated. 
Requirements  of  a  DBMS  are  also  summarized  in  Section  5.7. 

5.2  Components  Required  in  a 
Database  Management  System 

In  this  section  components  required  in  a  database  management  system 
for  structural  design  optimization  are  identified.  Various  components 
necessary  in  a  DBMS  and  their  functions  are  described.  An  overall  view 
of  the  workings  of  a  DBMS  are  given  below  to  show  main  events  that  take 
place  while  an  application  program  uses  a  DBMS: 

1.  An  application  program  calls  a  DBMS  to  define  a  database,  relation, 
and  matrices. 

?.  DBMS  checks  the  user  given  definition  for  syntax, 
i .  User  requests  DBMS  to  store  and  retrieve  data. 

'* .  DBMS  transfers  data  from  user  buffer  to  disk  and  vice  versa, 

n.  DBMS  stores  data  on  disk  in  files  at  addresses  allocated  for  data, 

n.  A  system  buffer  of  DBMS  is  used  as  an  intermediate  storage  to  avoid 
too  nany  disx  I/O  operation  for  data  transfer  between  user  buffer 
rm  disk.. 

If  a  DBMS  is  to  only  perform  operations  as  described  above,  then 
the  i  np'ementat  ion  for  such  a  DBMS  would  be  very  simple.  But  the 
requirement,  )f  structural  design  application  programmer  and  the  usage 
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pattern  are  highly  sophisticated  and  require  a  general  purpose  DBMS  to 
satisfy  their  needs.  Such  a  DBMS  should  have  components  —  command 
processors,  input-output  processors,  addressing  and  searching  routines, 
file  definition  and  operation  routines,  memory  management  routines, 
relational  operators,  and  security  schemes.  These  are  identified  in 
Fig.  5.2.1.  In  the  following  subsections,  functions  and  requirements  of 
these  components  are  described. 


5.2.1  Command  Processor 

User  given  commands  have  to  be  checked  before  they  are  executed  by 
a  DBMS  to  avoid  erroneous  operations  on  a  database.  Commands  of  DDL  and 
DML  involve  subroutine  call  statements,  whereas  query  language  commands 
contain  character  strings.  It  is  necessary  to  verify  these  commands  for 
syntax  and  also  against  illegal  use  of  commands  in  any  database 
operations.  In  the  case  of  subroutine  call  statements,  the  number  of 
arguments,  type  of  arguments  and  value  of  arguments  have  to  be 
verified.  For  example,  if  user  has  requested  operations  on  a 
nonexistant  database,  command  processor  must  issue  an  illegal  operation 
flag.  Interactive  user  is  bound  to  commit  a  large  number  of  mistakes 
while  issuing  commands  spontaneously.  Therefore,  a  more  sophisticated 
command  processor  is  required  to  verify  query  commands.  Such  a 
processor  has  to  provide  functions  for  verifying  character  strinys, 
storing  strings,  separating  data  items  from  a  command  string, 
identification  of  integer,  real  and  character  data  types  in  the  string, 
finding  the  length  of  a  command  line,  locating  next  item  in  a  command 
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Figure  5.2.1  Components  of  a  Database  Management  System 
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line,  automatic  generations  of  new  commands,  and  finding  repetitions  of 
previous  command  line. 


5.2.2  Input-Output  Processor 

Input-output  processor  is  the  basic  component  of  a  DBMS  which 
handles  all  requests  of  the  users  to  store,  retrieve,  modify  and  delete 
data.  Storage  and  retrieval  of  data  are  done  using  data  sets  and 
relations  as  a  unit.  Data  sets  are  nothing  but  sets  of  data  stored  in 
row,  column  or  submatrix  order.  Relation  is  a  two-dimensional  table  of 
data.  User  requests  to  store  or  retrieve  portions  (for  instance  a  set 
of  rows)  of  data  set  or  relation  are  satisfied  by  providing  data  in  the 
user  buffer.  Functions  of  I/O  processor  a^e  to  verify  the  correctness 
of  data  manipulation  operations  and  to  perform  data  transfer  between 
user  buffer  and  disk  files.  Existence  of  data  sets,  and  relations  are 
verified  before  any  data  is  transferred  between  user  buffer  and 
database.  If  the  data  manipulation  is  based  on  primary  keys,  then  I/O 
processor  checks  the  existence  of  key  values.  Most  of  structural  desiyn 
applications,  operates  on  rows  of  data  set  and  relations.  In  such  a 
case,  I/O  processor  is  required  to  verify  the  row  numbers  of  data  sets 
and  relations.  If  data  manipulation  is  based  on  certain  conditions  of 
data  value  in  a  data  set  or  a  relation  (for  example,  modify  coordinate 
values  of  nodes  5,  21,  and  27)  then  I/O  processor  is  required  to  provide 
capability  for  such  manipulations. 
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5.2.3  Addressing  and  Searching 

Input-output  processors  cannot  directly  get  the  required  data  from 
a  data  set  or  a  relation  till  the  address  to  the  stored  data  is 

determined.  Addressing  routines  determine  the  physical  storage  location 
for  a  data  set  or  a  relation  given  a  particular  row  number  or  primary 
key  values.  There  are  several  methods  to  determine  the  addresses. 
Important  methods  that  can  be  considered  for  implementation  are  indexing 
and  hashing  methods.  When  index  is  used  for  addressing,  address  to 

blocks  of  records  are  maintained  in  a  table.  In  hashing  method,  the 
primary  key  or  row  number  is  converted  into  a  random  number  and  is 
considered  as  the  address  for  the  data. 

Index  for  addresses  are  generally  large  if  database  is  big. 
Locating  a  particular  index  efficiently  is  important  to  save  time  of 
search.  Out  of  several  search  techniques,  B-tree  search  is  popular. 
One  index  is  placed  at  each  node  of  a  tree.  Search  begins  at  the  top  of 
a  tree  to  locate  a  particular  index.  Depending  on  whether  the  given 
index  is  less  than  or  greater  than  the  index  at  a  node,  search  is  made 
toward  left  or  right  of  the  tree. 

5.2.4  File  Definition  and  File  Operations 

At  the  physical  storage  level,  database  consists  of  either  a  single 
stored  file  containing  data  or  several  files  linked  together  as  a 

unit.  File  definition  and  file  operation  routines  are  required  in  a 

DBi'IS.  Function  of  file  definition  routine  are  naming  of  files, 
allocating  logical  unit  numbers,  specifying  type  of  file  access  (random 
or  sequential),  specifying  physical  storage  block  size,  etc. 


Actual  data  and  data  definitions  (name  of  data  set,  attributes, 
sizes)  may  be  stored  in  a  single  file  or  can  be  separately  stored  in 
different  files.  File  operations  consists  of  opening,  closing  and 
deleting  files.  A  file  once  opened  for  reading  and  writing  should  be 
closed  at  the  end  of  file  operations.  File  compression  is  needed  to 
recover  unused  space. 

5.2.5  Memory  Management 

Structural  design  application  programs  use  data  from  several  data 
sets  and  relations  at  a  particular  design  stage.  Also,  they  use  data  of 
different  portions  of  the  same  data  set  and  relation  in  arbitrary 
sequence.  In  such  situations,  we  are  faced  with  the  problem  of 
accommodating  the  required  data  in  the  primary  memory  and  at  the  same 
time  reduce  I/O  activity  to  lessen  computation  time.  Efficient  use  of 
primary  memory  is  possible  through  judicious  allocation  of  available 
space.  Memory  management  scheme  dynamically  controls  the  available 
memory  space.  The  memory  is  organized  into  pages  (which  is  a  unit  of 
transfer  between  the  database  and  primary  storage)  and  page  sizes  are 
assigned.  The  size  of  the  page  is  set  to  multiple  of  a  physical 
record.  Larger  the  page  size,  better  the  performance  as  less  I/O  is 
needed  to  get  the  required  data.  However,  space  may  be  wasted  if  there 
are  too  many  partially  filled  pages.  Small  page  size  leads  to  increase 
in  page  replacement  activity  and  maintenance  of  large  page  size  table. 
Variable  length  pages  require  tedious  programming  effort. 


Another  important  function  of  memory  management  routines  is  page 
replacement  activity.  Memory  management  scheme  should  keep  count  of  the 
pages  in  the  memory.  Paging  scheme  may  adopt  some  page  replacement 
algorithm.  Least  recently  used  (LRU)  page  replacement  is  the  most 
commonly  used  method.  In  LRU  algorithm,  a  page  counter  is  maintained 
for  each  page  and  updated  each  time  the  page  is  used.  When  a  page  is  to 
be  replaced,  the  page  with  the  highest  counter  value  becomes  the 
candidate.  A  page  replacement  is  needed  when  no  free  pages  are 
available.  A  page  not  modified  is  over  written  instead  of  replacement. 

Memory  management  scheme  should  be  developed  such  that  user  has 
some  control  over  the  size  of  pages.  This  feature  helps  in  determining 
the  appropriate  page  size  while  operating  on  larger  matrices  of  finite 
element  analysis  and  design  optimization  problems.  Fragmentation  of 
large  matrices  on  pages  can  be  avoided  by  using  page  size  in  multiples 
of  matrix  size.  Matrix  operation  algorithms  for  addition, 

multiplication  and  transpose  by  row  operations  can  use  page  size  in 
multiples  of  number  of  rows  of  a  matrix.  The  algorithms  that  solve 
large  order  simultaneous  equations  by  submatrix  approach  require  at 
least  a  few  submatrices  to  be  present  simultaneously  in  the  memory.  In 
such  a  case,  allocation  of  one  submatrix  per  page  induces  fewer  page 
faults.  This  leads  to  reduction  in  I/O  activity  of  iterative  algorithms 
and  brings  down  the  execution  time. 

5.2.6  Relational  Operators 

A  DBMS  which  operates  on  a  relational  database  must  have  relational 
operators  to  manipulate  the  database.  Relational  operators  manipulate 


data  in  terms  of  entire  sets  or  relations  and  not  in  terms  of  individual 
rows  or  columns  at  a  time.  Three  types  of  relational  operators  are 
INTERSECT,  PROJECT  and  JOIN.  Each  of  these  operators  take  either  one  or 
two  relations  as  its  operand  and  produces  a  new  relation  as  its 
result.  INTERSECT  operator  constructs  a  new  relation  by  selecting  rows 
of  two  relations  satisfying  certain  conditions  of  specified 
attributes.  The  PROJECT  operator  forms  a  vertical  subset  of  an  existing 
relation  by  extracting  specified  columns  and  removing  any  redundant 
duplicate  rows  in  the  set  of  columns  extracted.  The  JOIN  operator, 
joins  two  relations,  each  having  common  column  (attribute),  and  produces 
a  new  wider  relation  in  which  each  row  is  formed  by  concatenating  two 
rows,  one  from  each  of  the  original  relation,  such  that  two  rows  have 
the  same  value  in  those  two  columns. 

5.2.7  Security  Schemes 

Structural  design  database  is  used  by  a  number  of  application 
programs  and  users.  It  is  necessary  to  ensure  that  database  contents 
are  not  destroyed  or  manipulated  by  unauthorized  users.  Therefore,  DBMS 
must  have  special  scheme  to  ensure  security  of  a  database.  Security  of 
a  database  against  unauthorized  use  can  be  provided  by  allocating 
password  schemes  to  access  contents  of  a  database.  Users  of  database 
are  provided  with  read  and  modify  passwords  to  use  the  database 
accordingly.  These  passwords  can  be  assigned  both  at  database  level  and 
individual  dataset  or  relation  level. 


Data  definition  language  (DDL)  is  used  to  define  database,  relation 
and  matrices.  For  the  application  programmer,  DDL  is  a  conventional 
language  like  FORTRAN;  for  interactive  user  it  is  the  query  language. 
It  is  necessary  to  build  data  definition  language  such  that  they  do  not 
contain  reference  to  physical  storage  details  on  disk.  Thereby  any 
change  in  storage  structure  of  data  on  disk  will  not  force  modification 
of  application  programs. 

Data  definition  language  for  the  application  programmers  consist  of 
those  declarative  constructs  of  FORTRAN  needed  to  declare  database 
objects:  Variables  and  arrays,  FORTRAN  data  types,  extensions  to 
FORTRAN  to  support  objects  not  handled  by  FORTRAN.  Data  is  defined  by 
application  programmers  using  relations  and/or  matrices.  Since  FORTRAN 
does  not  provide  facility  to  express  relations  and  matrices,  we  need  to 
provide  extensions  to  FORTRAN  to  define  data.  Such  an  extension  is 
possible  through  FORTRAN  CALL  statements  and  is  provided  as  a  part  of 
DBMS.  Arguments  of  the  subroutine  call  statements,  for  example,  specify 
database  name,  re'ation  name,  attribute  name  and  size,  etc. 

Development  of  a  DDL  for  structural  design  application  should  be 
based  on  several  considerations.  One  of  the  major  consideration  should 
be  to  keep  syntax  of  DDL  concise  and  to  be  easily  understood  by 
application  programmers.  Furthermore,  since,  the  DDL  is  used  in 


structural  design  computing,  all  the  data  types  of  FORTRAN  must  be 
allowed  --  integer,  real,  double  precision  and  character.  Data  elements 
allowed  by  the  DDL  also  include  those  of  FORTRAN  scalars  and  arrays. 
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DDL  should  support  both  relation  and  matrix  definition.  Relation 
definition  require  specification  of  relation  names,  attributes  (names, 
type,  and  size),  key  attributes,  and  variable  length  attributes.  Matrix 
definition  requires  specification  of  matrix  name,  matrix  type,  row  size, 
column  size  and/or  submatrix  size.  Large  order  matrices  are  organized 
in  banded,  hyper  matrix  or  skyline  form.  Special  facilities  must  be 
provided  to  define  these  large  order  matrices.  There  are  many  instances 
in  structural  design  data  where  maximum  size  of  data  is  known.  For 
example  size  of  stiffness  matrix  is  known  in  advance.  In  such  a  case, 
provision  in  DDL  for  specification  of  maximum  number  of  data  occurrence 
will  enable  DBMS  to  conserve  storage  space  and  provide  maximum 
efficiency.  Another  feature  that  should  be  included  in  DDL  is  data 
redefinition  capability.  This  can  be  accomplished  by  providing  several 
transformation  of  the  same  data  to  different  application  programs.  It 
may  be  convenient,  for  instance,  to  represent  a  matrix  in  two  different 
ways  in  different  external  views.  In  one  view  the  matrix  might  be 
defined  as  two-dimensional  array  and  in  another  view  it  might  be  defined 
as  a  vector.  One  important  feature  that  should  be  incorporated  in  DDL 
of  structural  design  application  is  compilation  independent  data 
definition  facility.  This  means  that  DDL  must  have  facility  to  define 
data  types  and  relationships  during  run  time.  This  feature  is  necessary 
because  data  definition  in  many  instances  are  not  known  till  certain 
stage  of  processing  is  complete.  An  example  of  this  is  number  or 
degrees  of  freedom  which  is  not  known  to  define  size  of  assembled 
stiffness  matrix,  till  input  data  is  processed.  Finally,  consideration 
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for  development  of  DDL  should  include  database  security.  Mechanisms  for 
security  such  as  read  and  modify  password  must  be  provided  at  both 

relation  and  matrix  level. 

Based  on  the  above  requirements  a  DDL  for  structural  design 
application  is  proposed  and  its  syntax  given  in  the  Appendix  II.  DDL 
syntax  of  Appendix  II  uses  Backus-Naur  Form  (BNF)  as  a  tool  for  defining 
syntax  of  languages.  BNF  is  a  common  tool  for  formally  describing  a 
programming  language  syntax.  A  syntax  is  nothing  but  grammar  of  a 
language.  The  data  definition  language  has  following  features: 

1.  Database  definition  with  provisions  to  define  global  and  local 
databases.  Each  database  can  be  either  permanent  or  temporary. 
Temporary  meaning  that  database  is  deleted  at  the  end  of  execution. 

2.  Database  user  identification  provision.  Database  can  be  used 

either  by  a  owner  or  a  user.  Database  access  is  defined  either  by 
read  or  modify  rights. 

3.  Data  set  definition  facility  with  integer,  real  and  double 
precision  data  types.  Scalars,  vectors  and  matrices  can  be 
defi ned . 

4.  Relation  with  attributes  of  interger,  real  and  double  precision 

data  types.  Attributes  can  be  scalars,  vectors,  and  matrices. 

Provision  for  key  attributes  and  variable  length  attributes  are 

made . 

5.  Termination  of  data  set  definition  and  data  redefinition  facility 


6.  Numerical  data  definition  with  provision  to  define  square, 
triangular,  banded,  hyper  and  skyline  matrices  is  provided. 


Oata  manipulation  language  (DML)  is  used  to  store,  retrieve,  modify 
and  delete  data  in  a  database.  For  application  programmers  DML  is 
provided  through  subroutine  call  statement;  for  interactive  user  it  is 
provided  through  query  language. 

Development  of  a  DML  for  structural  design  application  should  be 
based  on  several  considerations.  The  DML  commands  should  be  simple  as 
they  are  frequently  used  in  an  application  program.  The  DML  should  not 
contain  any  reference  to  the  storage  structure  details.  DML  should  have 
capability  to  access  data  from  different  databases.  Relations  and 
matrices  are  frequently  accessed  and  stored  row-wise.  Therefore, 
commands  in  DML  must  facilitate  this  operation.  Also,  it  should  be 

possible  to  store  and  retrieve  rows  in  a  sequential  order  or  in  a  random 
order.  Further,  each  row  can  contain  data  from  a  set  of  attributes  each 
belonging  to  different  data  type  —  integer,  real,  double  precision. 
Therefore,  commands  should  be  designed  to  accommodate  multiple  data 
types  for  data  manipulation  operations.  Many  structural  design 

application  programs  require  data  of  a  particular  attribute  of  a 
relation.  For  example,  some  programs  need  only  degree  of  freedom 

attributes  in  a  node-coordinate-degree  of  freedom  relation. 

Consideration  in  design  of  DML  should  include  data  manipulation  in  terms 
of  single  attributes  or  a  set  of  attributes.  Further,  it  should  be 
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possible  to  select  any  required  values  from  an  attribute  that  satisfies 
certain  conditions.  Special  commands  must  be  provided  in  DML  to  specify 
conditions  on  data  values  that  are  to  be  manipulated. 

Further  consideration  in  the  design  of  DML  is  based  on  matrix 
manipulation  requirements.  Large  ^rder  matrices  are  generally 
storeu  and  retrieved  row-wise,  column-wise  and  submatrix-wise.  Data 
manipulation  commands  must  include  operators  to  manipulate  matrix  data 
in  terms  of  rows,  columns  and  submatrix  order.  Matrix  operations  such 
as  transpose,  multiplication  require  column-wise  retrieval  of  data 
stored  in  row-wise  pattern.  Special  provisions  should  be  made  in  the 
commands  to  indicate  null  rows  (zero  elements  in  a  row),  null  columns 
and  null  submatrices. 

There  are  a  number  of  other  considerations  for  designing  DML. 
Commands  should  include  utility  and  data  definition  list  facility. 
Utility  commands  of  DML  are  open  database,  close  database  and  error 
display  commands.  Commands  should  be  able  to  provide  facility  for 
opening  and  closing  of  a  number  of  databases  at  various  stages  of 
execution.  Data  definition  list  command  will  enable  application 
programmer  to  check  and  use  detailed  definition  of  data  objects  stored 
in  the  database.  Error  display  commands  facilitate  application 
programmer  to  investigate  the  cause  of  errors. 

Based  on  the  above  requirements  a  DML  for  structural  design 
application  is  proposed  and  its  syntax  given  in  Appendix  III.  DML 
syntax  of  Appendix  III  is  given  in  Backus-Naur  Form.  Description  of  BNF 
are  same  as  those  given  for  DDL.  The  data  manipulation  language  has  the 
following  features: 
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1.  Commands  to  open  and  close  a  database. 

2.  Retrieval  command.  This  has  facility  to  retrieve  data  set  a^d 
rel ation . 

3.  Store  command  to  fill  data  set  and  relations  with  values. 

4.  Command  to  delete  parts  of  data  sets  and  relations. 

5.  Command  to  modify  parts  of  a  data  set  or  a  relation. 

6.  Remove  command  to  eliminate  a  data  set  or  a  relation. 

7.  Command  to  copy  data  from  one  data  set  or  relation  to  another. 

8.  Store,  retrieve,  modify  and  delete  commands  for  matrix  data. 

9.  Rule  command  to  specify  conditions  on  data  values  that  have  to  be 
retrieved . 


Structural  designers  often  want  to  use  a  database  interactively  to 
find  out  various  parameters  of  design  and  to  modify  them  by  using  simple 
commands.  Query  language  provides  a  simple  set  of  commands  to 
interactively  define  and  manipulate  data  in  a  database.  It  can  be  used 
by  any  nonprogramming  user  and  does  not  require  knowledge  of  high  level 
languages  like  FORTRAN.  Data  definition  of  query  language  includes 
database,  relation  and  attribute  definition,  rule  specification,  and 
authorization  procedures.  Data  manipulation  of  query  language  includes 
store,  retrieve,  modify  and  delete  commands.  In  addition  to  these 
commands  relational  operators  like  INTERSECT,  PROJECT  and  JOIN  are 
requi red . 
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A  query  language  should  satisfy  several  requirements.  These  are 
data  independence,  simplicity,  nonprocedural i ty ,  extendabi 1 i ty  and 
completeness.  Data  independence  refers  to  independence  of  logical  data 
structure  and  storage  structure  definition.  Query  language  should  not 
contain  any  reference  to  storage  structure.  Nonprocedural i ty  means  that 
user  should  be  allowed  to  give  commands  in  any  arbitrary  order  and 
should  not  restrict  them  to  follow  procedures  to  query  a  database. 
Query  language  should  be  easily  extendable  to  incorporate  any  special 
function  into  it.  Query  language  should  be  complete  in  the  sense  that 
it  possesses  all  the  required  commands  to  query  all  types  of  data  in  the 
database.  Query  commands  must  be  general  and  not  limited  to  any  special 
case.  Query  of  large  order  matrices  requires  special  features  in  query 
language  so  that  data  can  be  displayed  in  parts. 

General  syntax  of  a  query  language  is: 

<command>  <Expressior  ,  clause>  <conditional  clause> 

The  command  is  a  name  interpreted  by  a  DBMS  to  execute  certain  procedure 
for  defining  and  manipulating  data.  Some  typical  commands  required  for 
structural  design  are  SELECT,  LIST,  CHANGE,  RENAME,  OPEN,  CLOSE,  LOAD, 
DEFINE,  and  EXIT.  The  second  component  is  expression  clause  which  is  a 
group  of  words  specifying  names  of  relation  and  attributes.  The  third 
component,  conditional  clause,  allows  a  user  to  specify  a  condition  on 
the  data  for  which  command  is  executed.  The  conditions  may  be,  for 
example,  GT.100;  LT.20,  ROWS. EQ. 10. 
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5.6  A  Review  of  Database  Management  Systems 

In  this  section,  a  review  of  existing  database  management  systems 
is  made.  This  review  (Sreekanta  Murthy  and  Arora,  1985a)  enables  us  to 
evaluate,  select  and  modify  a  database  management  system  so  that  it 
could  be  used  in  computer-aided  structural  analysis  and  design 
optimization.  The  following  fifteen  database  management  systems  are 
reviewed.  The  capability  of  these  systems  are  emphasized  and  important 
features  are  tabulated. 


DELIGHT  -  Design  Language  with  Interactive  graphics  and  a  Happier 
Tommorow 

DATHAN  -  A  data  handling  program  for  finite  element  Analysis 

EDIPAS  -  An  Engineering  Data  Management  System  For  CAD 

FILES  -  Automated  Engineering  Data  Management  System 

GIFTS  -  GIFTS  Data  Management  System 

GLIDE  -  GLIDE  Language  with  Interactive  graphics 

ICES  -  Integrated  Civil  Engineering  System 

IPIP  -  Information  Processor  for  IPAD 

PHIDAS  -  A  Database  Management  System  for  CAD 

REGENT  -  A  System  for  CAD 

RIM  -  Relational  Information  Management  System 
SDMS  -  A  Scientific  Data  Management  System 
SPAR  -  SPAR  database  management  system 
TORNADO  -  A  DBMS  for  CAD/CAM  system 


DELIGHT.  It  stands  for  Design  Language  with  Interactive  Graphics 
and  a  Happier  Tommorow  (Nye,  1981;  Balling,  Pi  ester  and  Polak,  1983). 
In  its  philosophy,  the  DELIGHT  system  is  very  close  to  the  GLIDE  system 
(Eastman  and  Henrion,  1980).  DELIGHT  is  an  interacive  programming 
language.  It  has  good  extension  and  debugging  capability.  It  provides 
nigh-level  graphic  commands,  a  built-in  editor  and  a  well-defined 
interface  routines.  A  single  statement,  procedure  or  part  of  an 
algorithm  can  be  tested  without  having  to  write  and  load/link  a 
program.  The  system  relies  on  virtual  memory  management  of  the 
operating  system.  It  is  difficult  to  use  the  system  with  large  scale 
programs.  Multiple  users  are  not  allowed  in  the  system. 

DATHAN.  It  stands  for  data  handling  program.  It  is  written  mainly 
for  finite  element  analysis  applications  (Sreekanta  Murthy  and  Arora, 
1983).  The  program  has  some  basic  in  core  buffer  management  scheme.  It 
has  capability  to  store  permanent  and  temporary  data  sets.  Substructure 
files  can  be  arranged  quite  easily  with  same  data  set  names  for 
different  substructures .  Both  integer  and  real  data  types  can  be 
Handled.  Drawback  of  the  system  is  that  the  user  has  to  keep  track  of 
the  location  from  which  a  new  data  set  has  to  begin.  The  system  has 
RKTKAN  data  manipulation  commands  which  are  simple  to  use. 

EOIPAS.  It  stands  for  Engineering  Data  Interactive  Presentation 
and  Analysis  System,  (Heerema  and  van  Hedel  ,  1983).  It  is  a  tool  for 
data  management ,  analysis,  and  presentati on .  The  data  management  part 
provides  a  utility  to  initalize  a  project  database,  input  programs  to 


load  data  from  files  into  database  under  user  controls,  and  a  set  of 
routines  to  extract  data  from  and  load  data  into  database  in  a 
controlled  way.  EDIPAS  allows  users  to  name  a  database,  a  data 
structure,  and  data  entities.  It  allows  user  to  employ  one  or  more 
hierarchical  levels.  The  data  is  stored  in  entities  called  blocks.  A 
data  block  allows  matrices,  single  values  and  characteri stic  values  as 
data  elements.  A  database  administration  support  provides 
ini tial i zation  of  database ,  access  to  users ,  deletion  of  data 
structures,  audit  database  contents,  and  back-up  facility.  The  system 
does  not  have  data  redefinition  facility.  Improvements  are  beiny  done 
to  include  redefinition  facility  in  order  that  the  data  structures  and 
their  levels  can  be  manipulated.  Extension  of  authorization  provision 
from  database  level  to  the  level  of  data  element  is  being  incorporated. 

FILES.  It  is  an  automated  engineering  data  management  system 
(Lopez,  1974).  It  is  extremely  flexible  with  respect  to  the 
definition  of  a  database  and  methods  of  accessing  it.  Information 
storage  and  retrieval  may  be  performed  using  problem-oriented 
languages.  Hierarchical  data  structure  is  provided.  For  example  matrix 
type  of  data  encountered  in  finite  element  application  can  be  organized 
using  hierarchical  data  structure.  The  first  two  levels  in  hierarchy 
may  contain  pointers  to  the  third  level  containing  actual  matrix  data. 
The  program  allows  dynamic  memory  allocation.  Data  transfer  takes  place 
between  FORTRAN  common  block  and  database.  FILES  has  a  data  definition 
language.  The  system  does  not  have  data  mapping  language  to  specify 
mapping  of  data  items  and  arrays  to  an  external  device.  The  data 


definition  language  (DDL)  depends  on  the  problem  oriented  language 
(POL).  Therefore  DDL  cannot  be  used  independently.  The  system  requires 
a  distinct  data  management  compiler. 

GIFTS.  It  is  an  interactive  program  for  finite  element  analysis 
(Kamel,  McCabe  and  Spector,  1979).  It  is  a  collection  of  modules  in  a 
program  library.  Individual  modules  run  independently  and  communicate 
via  the  unified  database.  The  database  manager  processes  requests  for 
opening  a  file,  closing  a  file,  storing  data  set  in  a  file,  and 
retrieving  data  set  from  a  file.  The  program  has  memory  management 
scheme.  Each  data  set  is  stored  in  a  separate  random  access  file. 
Paging  is  carried  out  within  the  working  storage.  A  unique  set  of  four 
routines  is  associated  with  a  data  set  for  opening  and  initializing  the 
working  storage,  for  reading  a  data  set,  for  creati ng/modi fyi ng  the  data 
set,  and  for  realizing  the  working  storage.  Drawbacks  of  the  system  is 
that  every  new  data  set  requires  created  four  new  routines  to  be 
written.  Each  data  set  is  associated  with  a  separate  common  block, 
thereby  increasing  the  number  of  common  blocks  in  the  system.  The  data 
manager  is  application  dependent  and  cannot  be  used  as  a  stand  alone 
system . 

GLIDE.  it  is  a  context-free  database  management  system  (Eastman 
and  denrion,  1980).  It  is  designed  to  provide  a  high  level  facility  for 
developing  individual i zed  CAD  system.  It  can  be  viewed  as  a  language,  a 
■la  tab  as.:  Manage- lent  system,  and  a  geometric  modelling  system.  It  allows 
user*,  to  define  new  record  types  Known  as  FORM  that  consist  of  a  set  of 


attribute  field.  It  provides  primitive  data  type  set  to  organize  a 
database.  It  provides  excellent  geometric  modelling  system  or  a  graphic 
system.  Drawback  of  GLIDE  is  that  it  does  not  allow  multi-dimensional 
arrays . 

ICES.  Integrated  Civil  Engineering  System  is  a  computer  system 
designed  for  solving  civil  engineering  problems  (Roos,  1966).  ICES 
consists  of  a  series  of  subsystems  each  corresponding  to  an  engineering 
discipline.  It  provides  a  Problem  Oriented  Language  which  can  be  used  to 
write  subsystem  programs  (e.g.,  coordinate  geometry  program,  stress 
analysis  program).  Command  Definition  Language  is  used  by  a  programmer 
to  specify  the  structure  and  required  processing  for  each  subsystem 
commands.  A  Data  Definition  Language  is  used  to  specify  the  subsyten 
data  structure.  It  uses  its  own  programming  language  called  ICETRAN 
(ICES  FORTRAN)  and  has  a  precompiler  which  translates  ICESTRAN  to 


FORTRAN  statements. 

Dynamic  data  structuring  capability  is  provided  in  the  system 
which  helps  to  organize  dynamic  arrays  in  the  primary  memory. 
Hierc'chical  data  structure  is  used  for  data  modelling.  Three 
hierarchical  levels:  equivalence  class,  members,  and  attributes  are 
provided.  Data  is  stored  on  secondary  storage  using  random  access 
files.  Data  management  program  uses  buffers  to  convert  logical  records 
to  physical  records.  Identifier  is  supplied  by  the  programmer  which  is 
a  pointer  giving  the  position  on  secondary  storage  of  physical  record. 
The  programmer  has  a  choice  to  store  data  using  dynamic  arrays  or  using 
data  management  system  depending  on  amount  and  use  of  the  data . 


Drawback  of  the  system  is  that  it  uses  precompiler  ICETRAN  to  convert  to 

KiWTKAN  program  instead  of  directly  to  machine  language.  Physical 

storage  of  data  requires  knowledge  of  address  and  pointers  which  the 
programmers  have  to  give.  Only  three  levels  of  hierarchy  is  adopted  and 
it  is  difficult  to  extend  to  many  levels  of  hierarchy. 

IPIP.  It  is  a  state-of-the-art  database  management  system 
satisfying  engineering  requirements  (Johnson,  Comfort  and  Shull, 

1980).  It  offers  a  number  of  capabilities  ranging  from  support  for 
multiple  schemas  and  data  models  to  support  for  distributed  processing, 
and  data  support  for  distributed  processing,  and  data  inventory 

management.  An  integrated  software  architecture  supports  all  user 
interfaces:  programming  languages,  interactive  data  manipulation  and 

schema  languages.  IPIP  supports  a  multiple-schema  architecture  of 
ANSI/ SPARC  database  group.  Three  types  of  schemas  —  conceptual, 
external  and  internal  schemas  are  supported.  IPIP  schema  and  data 
manipulation  languages  exhibit  a  high  degree  of  integration  and 
compatibility.  The  logical  schema  supports  both  the  network  and 
rel a  1 1  >n  1 1  data  models,  and,  functional ly ,  the  hierarchical  data 
model.  The  internal  schema  of  IPIP  is  written  using  the  internal  schema 
language  compiler.  The  internal  schema  language  overlaps  that  of  the 
logical  schema  language  to  the  greatest  practical  extent  to  minimize  the 
amour:  of  schema  language  with  which  the  admi ni strator  must  deal.  IPIP 
software  subcomponents  consists  of  user  interface,  and  data  manager. 
Software  of  user  interface  is  made  of  precompilers,  query  processor  and 
r unpliers.  Data  manager  software  is  made  of  scheduler,  message 


procedure  interface  processor,  nmmon  semantic  processor,  database 
control  subsystem,  data  manipulation  subsystem,  record  translator, 
presentation  service,  access  module,  resource  manager  and  stubs. 

PHIDAS.  It  is  a  data  management  system  specially  designed  for 
handling  a  collection  of  structured  data  on  minicomputers  (Fischer, 
1979).  The  architecture  of  PHIDAS  is  in  accordance  with  the  ANSI-3 
schema.  It  has  an  external  subschema  based  on  network  model  of  CODASVL 
and  an  internal  schema  for  physical  tuning  particularly  suited  for 
engineering  database.  The  data  description  language  is  provided  to 
describe  schema  and  sub-schema.  PHIDAS  also  has  a  storage  structure 
description  language.  Data  manipulation  language  is  FORTRAN  call 
statements  to  subroutines.  Drawback  of  the  system  is  that  it  is 
difficult  to  represent  matrix  type  data. 

RIM.  It  stands  for  Relational  Information  Management  system 
(Comfort,  Erickson  1978).  RIM  has  capability  to  create  and  modify  data 
element  definition  and  relationships  without  recompiling  the  schemes  or 
reloading  the  database.  RIM  provides  capability  to  define  new  types  of 
data  for  use  in  special  application  such  as  graphics.  RIM  supports 
three  types  of  data:  real,  integer,  and  text.  Data  definition  and  data 
manipulation  languages  are  available  to  define  or  manipulate 
relations.  The  user  has  capability  to  project,  intersect,  join  and 
subtract  relations.  RIM  has  good  query  language.  RIM's  modification 
commands  permit  the  user  to  update  relation  definition,  change  data 
values,  attribute  names,  delete  tuples  and  delete  the  entire  relation. 


Utility  commands  such  as  LOAD,  and  EXIT  are  provided  to  load  a  new 
database  and  close  an  existing  database.  Drawback  of  RIM  is  that  it 
does  not  allow  relation  having  row  size  more  than  1024  computer  words. 
The  application  oriented  FORTRAN  call  statements  do  not  have  capability 
to  define  attributes,  relations,  rules,  etc.,  required  in  defining  a 
schema.  The  system  does  not  support  management  of  a  temporary 
database.  Simultaneous  operations  on  a  number  of  databases  is  not 
possible. 

REGENT.  It  is  a  system  for  the  support  of  computer-aided  design 
(Leinemann  and  Schl echtendahl  ,  1976).  The  main  goal  of  the  development 
was  to  provide  a  so-called  "system  nucleus"  in  the  sense  of  ICES. 
Improvement  claimed  for  the  system  is  that  it  has  a  powerful  base 
language  PL/1  instead  of  FORTRAN.  Interactive  use  has  been  considered 
in  system  development.  The  database  management  of  REGENT  provides 
facilities  to  compress  a  database,  copy  data  between  databases,  and  to 
change  name  and  size  of  data  elements.  The  database  of  REGENT  is  not  a 
database  in  the  usual  sense.  It  is  some  sort  of  partitioned  data  set 
concept,  built  up  using  a  tree  structure  of  sequential  files,  but  the 
internal  structure  of  these  files  is  known  only  to  those  programs  that 
use  then. 

SDMS.  It  is  a  database  management  system  developed  specifically  to 
support  scientific  programming  applications  (Massena,  1978).  It 
consists  of  a  data  definition  program  to  define  the  form  of  databases, 
and  FORTRAN  compatible  subroutines  to  create  and  access  data  within 


them.  Database  contains  one  or  more  data  sets.  A  data  set  has  form  of 


a  relation.  Each  column  of  a  data  set  is  defined  to  be  either  a  key  or 
data  element.  Key  must  be  a  scalar.  Data  elements  may  be  vectors  or 
matrices.  The  element  in  each  row  of  the  relation  forms  an  element 
set.  Temporary  database  capability  that  vanishes  at  the  end  of  a  job  is 
provided.  A  scientific  data  definition  language  provides  a  program- 
independent  data  structure.  Both  random  and  sequential  access  of  data 
set  is  possible.  Data  elements  include  scalars,  fixed  and  variable 
length  vectors,  fixed  and  variable-size  matrices.  Data  element  types 
include  text,  real  and  integer.  Drawback  of  the  system  is  that  it  does 
not  have  a  query  language.  Generalized  database  load/unload  is  not 
available.  Double  precision  data  type  is  not  allowed.  The  system  is 
implemented  only  on  Cyber  series  computers. 

SPAR.  The  computer  program  is  a  collection  of  processors  that 
perform  particular  steps  in  finite  element  analysis  procedure 
(Whetstone,  1977).  The  data  generated  by  each  processor  is  stored  on  a 
database  compiler  that  resides  on  an  auxiliary  storage  device.  Each 
processor  has  a  working  storage  area  that  contains  the  input  and  the 
computed  data  from  the  processor.  Allocation  of  spaces  in  the  storaye 
area  is  a  problem  dependent  and  is  dynamically  allocated  during 
execution.  Data  transfer  takes  place  directly  between  a  specified 
location  on  disk  using  a  set  of  data  handling  utilities.  SPAR  database 
complex  is  composed  of  26  data  libraries  or  data  files.  Libraries  1  to 
20  are  available  for  general  use.  Libraries  21  to  26  are  reserved  for 
temporary  and  internal  use.  The  database  manager  uses  a  master  directory 


to  locate  the  table  of  contents  which  in  turn  is  used  to  locate  the  data 


sets  in  the  database.  Physically,  the  auxiliary  storage  is  divided  into 

sectors  of  fixed  size  and  each  read/write  operation  begins  at  the 

neginning  of  a  sector.  Drawback  of  the  system  is  that  it  does  not 
provide  either  hierarchical  or  relational  data  structure.  Excessive 
fragmentation  may  take  place  if  the  sector  size  does  not  happen  to  be  an 
integral  multiple  of  the  data  that  is  stored. 

TORNADO.  It  is  a  DBMS  system  developed  for  CAD/CAM  application 
(Ulfsoy,  Steiner  and  Oian,  1979).  It  is  a  CODASYL  network  system 

written  in  FORTRAN  and  is  very  useful  for  handling  complex  data 
structures.  It  handles  variable  object  length  and  dynamic  length 

records.  System  allows  different  data  types  -  integer,  real,  character, 
double  precision,  double  integer,  complex  and  logical  data.  The  system 
has  easy  to  use  data  definition  language  and  data  manipulation 
language.  TORNADO  system  is  highly  portable.  Data  in  the  database  can 
be  accessed  by  name.  There  is  no  restriction  on  data  set  types  and 
allows  many-to-many  relationships.  Drawback  of  the  system  is  that  the 
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(Ronald,  1978).  The  system  allows  arrays  of  integer,  real  double 
precision  and  character  data  storage.  Both  random  access  and  sequential 
access  of  data  is  provided.  Variable  length  record  I/O  is  allowed  in 
the  system.  Bit  map  scheme  is  used  to  identify  the  unused  space  for 
storage  of  data  to  minimize  disk  storage  requi rement .  The  program 
allows  restart  facility  using  saved  file  following  completion  of  a 
partial  execution  or  after  a  program  termination.  The  system  at  present 
is  only  implemented  on  I8M360  or  DEC  P0P11  computing  systems.  The 
system  does  not  provide  data  definition  language.  It  does  not  provide 
either  hierarchical  or  relational  data  structures. 

5.7  Summary  of  Requi rements  of  a  DBMS 

Capabilities  of  various  systems  are  summarized  in  the  Table 
5.7.1.  We  identify  the  following  requirements  of  a  DBMS  for  computer- 
aided  structural  design  otpimization  (Sreekanta  Murthy,  Shyy  and  Arora, 


! 


1985) : 

1.  As  FORTRAN  is  the  host  language  for  majority  of  the  engineering 
applications,  it  is  necessary  to  provide  application  interface  with 
DBMS  through  standard  FORTRAN  statements. 

2.  Data  model  provided  in  DBMS  must  be  easy  to  understand  and  apply 
for  design  application  programmers  and  users.  Data  model  must  be 
flexibile  to  suit  the  requirements  of  different  applications. 
Relational  and  numerical  data  models  are  desirable. 

3.  Since  the  system  will  be  used  for  design  optimization  in 
multidisciplinary  environment,  it  must  be  an  application- 
independent  DBMS. 
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Design  data  consists  of  arrays  and  matrices  to  a  large 
extent.  Often  matrix  data  are  in  the  form  of  banded,  subinatrix, 
and  triangular.  A  suitable  data  model  is  therefore  required  to 
organize  matrix  data. 

DBMS  should  be  able  to  deal  with  various  data  types  such  as 
characters,  short  integers,  long  integers,  single  precision,  double 
precision,  and  complex  numbers. 

Speed  of  storage  and  retrieval  is  one  of  the  most  important 
requirements  of  a  DBMS  in  design  optimization.  Short  access  time 
will  considerably  reduce  the  total  execution  time  in  an  iterative 
nature  of  design  process. 

Simple  to  use  data  definition  and  data  manipulation  languages  are 
required.  Applications  often  define  data  dynamically.  For 

example,  size  of  various  matrices,  length  of  data,  etc.,  are  not 
known  at  compilation  time.  They  are  also  modified  frequently.  It 
is  necessary  to  provide  data  definition  capability  to  cater  to 
these  special  needs. 

DBMS  should  provide  additional  capability  to  organize  the  available 
primary  memory.  A  suitable  memory  management  scheme  should  be 
i n  :orporated . 

A  good  query  language  is  required  for  interactive  design 

applications.  Query  language  snould  be  general  to  cover  all 
appl i cati ons . 
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Provision  for  managing  a  temporary  database  will  considerably  help 
designers  in  evaluating  trial  designs  and  transfering  the 
acceptable  final  design  to  a  permanent  database.  Temporary 
databases  will  also  be  needed  in  iterative  design  optimization 
process.  Thus,  DBMS  must  be  able  to  handle  multiple  databases 
simultaneously. 


Table  5.7.1  Features  of  Various  Database  Management  Systems  for  Engineeging  Applications 


CHAPTER  6 


IMPLEMENTATION  OF  A  DATABASE 
MANAGEMENT  SYSTEM  —  MIDAS 

6.1  Introductory  Remarks 

A  database  management  system  -  MIDAS*  has  been  implemented  for 
finite  element  analysis  and  structural  design  optimization  applications 
(Sreekanta  Murthy,  Shyy,  and  Arora,  1986).  The  MIDAS  implementation  is 
based  on  the  requirements  of  a  database  management  system  given  in 

Chapter  V.  MIDAS  has  two  subsystems  -  MIDAS/R  and  MIDAS/N.  These 
subsystems  are  capable  of  organizing  data  of  relational  and  numerical 
models,  respectively.  The  system  has  been  installed  on  PRIME  computer 
system.  It  was  decided  to  use  an  existing  package  as  much  as 

possible.  RIM  is  the  most  advanced  system  available  for  scientific 
database  management.  It  supports  relational  data  model  facility,  so  it 
was  decided  to  see  if  the  system  could  be  extended  to  satisfy  the 
requirements  stated  in  Chapter  5.  It  was  found  difficult  to  extend  RIM 
to  have  multiple  databases,  to  organize  large  matrices,  and  to  be 
efficient  in  handling  large  data  sets  and  large  memory.  It  essentially 
meant  rewriting  the  memory  management,  and  data  definition  and 
manipulation  parts.  So,  it  was  decided  to  use  RIM  as  is  but  add  new 
data  definition  and  data  manipulation  subroutines  that  could  be  called 


*(Hanagement  of  Information 


for  Design  and  Analysis  of  Systems) 


from  a  FORTRAN  application  program.  Also  a  memory  management  routine  is 


added.  This  sybsystem  is  called  MIDAS/R  which  stands  for  MIDAS- 
Relational  Data  Management  System. 

A  second  subsystem  called  MIDAS/N  was  designed  (Shyy,  1985)  which 
stands  for  MIDAS-Numerical  Data  Management  System.  MIDAS/N  supports 
numerical  data  model  facility.  This  subsystem  can  handle  multiple 
databases,  small  and  large  matrices,  and  small  and  large  memory 
environment.  Large  matrices  such  as  rectangular,  square,  upper- 

triangular,  lower  trinagular  and  hypermatrices  can  be  defined  in  the 
database.  Matrix  data  can  be  arranged  in  row,  column  or  submatrix 
order.  MIDAS  relieves  the  burden  of  managing  data  for  application 
programmers  by  providing  user-friendly  application  commands.  The  system 
has  sophisticated  interactive  commands  to  query  the  database.  The  MIDAS 
system  can  be  used  either  interactively  or  through  application 
programs.  The  implementation  details  of  MIDAS/R  and  description  of 
MIDAS/N  are  given  in  Sections  6.2  and  6.3,  respectively. 

6.2  Implementation  of  MIDAS/R 

In  this  section,  capabilities,  database  organization,  data 
definition,  data  manipulation  and  query  commands  of  MIDAS/R  are 
described.  Also,  details  of  the  system  architecture  are  given.  MIDAS/R 
database  management  system  is  based  on  relational  data  model.  The 
system  is  developed  by  modifying  and  extending  the  RIM  program 
(Relational  Information  Management  System). 
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6.2.1  Capabilities  of  MIDAS/R 

MIDAS/R  is  written  in  FORTRAN-77.  The  system  does  not  have  any 
machine  dependent  instructions  and  therefore  it  is  highly  portable.  It 
has  data  definition  and  data  manipulation  commands  which  are  simple  to 
use  for  application  programmers.  It  has  sophisticated  interactive 
commands  to  query  the  database,  modify  the  database  and  display  the 
database  schema.  The  system  has  capability  to  store,  retrieve,  modify 
and  delete  a  database  using  both  application  call  statements  and 
interactive  commands.  The  data  can  be  integer,  real,  double-precision 
and  character  words.  The  data  can  be  organized  in  the  form  of 

relations.  The  system  has  powerful  relational  algebra  commands  like 
INTERSECT,  PROJECT  and  JOIN.  MIDAS/R  has  capability  to  provide  access 
to  the  database  simultaneously  for  multiple  users.  Database  security  is 
provided  through  two  level  password  system.  Error  recovery  mechanisms 
are  available. 

6.2.2  Database  of  MIDAS/R 

MIDAS/R  has  capability  to  create  a  number  of  databases.  The 

databases  can  be  used  one  at  a  time.  The  database  can  be  either 
permanent  or  temporary.  The  size  of  a  database  is  unlimited  but  depends 
only  on  the  availability  of  disk  space.  Database  of  MIDAS/R  can  hold 

any  number  of  relations  each  of  which  is  identified  by  a  unique  name.  A 

relation  can  store  data  of  a  number  of  attributes.  An  attribute  value 
can  be  a  single  data  item,  a  vector  or  a  matrix.  Variable  length  rows 
of  a  relation  can  be  stored. 


6.2.3  Data  Definition  Commands  of  MIDAS/R 


Data  definition  commands  are  used  in  an  application  program  to 


define  a  database,  relations  and  attributes.  These  commands  are  FORTRAN 


subroutine  call  statements.  These  commands  were  not  available  in  RIM 


program.  The  data  definition  commands  of  MIDAS/R  are  described  in  the 


following  paragraphs. 


Database  Initialization. 


CALL  RDBINT 


This  command  initializes  MIDAS/R.  Before  using  any  other  commands 


of  the  system,  this  command  must  be  used. 


Database  Definition. 


CALL  RDBDFN  (NAME,  STAT,  IERR) 


NAME  =  Name  of  the  database 


STAT  =  Permanent  or  temporary  status  of  the  database 


IERR  =  Error  Code 


A  unique  database  can  be  defined  using  this  command.  A  temporary 


database  is  deleted  when  it  is  closed, 


Relation  Definition. 


CALL  RELQFN  (NAME,  RNAME,  NCOL,  CNAME,  CTY PE,  IELM,  JELM,  KEY, 


IERR) 


=  Name  of  tne  database 


RNAME  -  Relation  name 


=  Number  of  attrioute  columns 


=  A  vector  of  attribute  names 
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CTYPE  =  A  vector  of  attribute  type 

IELM  =  A  vector  of  row  size  of  attributes 


JELM  =  A  vector  of  column  size  of  attributes 

KEY  =  A  vector  of  key  attribute  indicator 

IERR  =  Error  code 

A  relation  can  be  defined  using  this  command.  Relation  name  and 
attribute  names  must  be  unique  in  a  database.  A  row  and  column 
intersection  in  a  relation  table  can  contain  either  a  single  data  item, 
a  vector  or  a  matrix.  Details  of  data  type  and  layout  of  data  in  a 
typical  relation  are  given  in  Figs.  6.2.1  and  6.2.2,  respectively. 


Data  Set  Definition. 

CALL  RDSDFN  (NAME,  DSNAME,  DTYPE ,  IELM,  JELM,  IERR) 

NAME  =  Name  of  the  database 
DSNAME  =  Name  of  the  data  set 
DTYPE  =  Data  type  (see  Fig.  6.2.1) 

IELM  =  Row  size  of  a  attribute  (see  Fig.  6.2.1) 

JELM  =  Column  size  of  a  attribute  (see  Fig.  6.2.1) 

IERR  =  Error  code 

A  data  set  is  defined  as  a  collection  of  data  belonging  to  same 
data  type  such  as  single  data  item,  vector,  or  matrix.  In  a  sense,  a 
data  set  is  a  relation  having  only  one  attribute.  Name  of  data  set  has 
to  be  unique  in  a  database. 
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Description 

TYPE 

IELM 

JELM 

Integer 

I  NT 

1 

1 

Real 

REAL 

1 

1 

Double  Precision 

DOUB 

1 

1 

Integer  Vector 

IVEC 

n 

1 

Real  Vector 

RVEC 

n 

1 

Double  Precision  Vector 

DVEC 

n 

1 

Integer  Matrix 

IMAT 

m 

n 

Real  Matrix 

RMAT 

m 

n 

Double  Precision  Matrix 

DMAT 

m 

n 

Text  or  Character 

TEXT 

n 

1 

NOTE:  Values  of  IELM  and  JELM  if  0  indicate  that  data  is  of  variable 
length. 


Figure  6.2.1  Data  Type  and  Size  of  a  Relation 
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Data  Set  Redefinition. 


CALL  RDRDFN  (NAME,  DSNAME,  DTYPE,  IELM,  JELM,  IERR) 

Arguments  are  same  as  in  data  set  definition.  This  command 
redefines  a  data  set  using  new  data  type,  and  new  attribute  size.  Old 
data  set  definition  and  its  data  is  lost. 

Data  Definition  Ending. 

CALL  RDSEND  (IERR) 

IERR  =  Error  Code 

After  database,  relations  and  data  sets  have  been  defined,  data 
definition  process  is  ended  by  calling  this  routine.  During  execution 
of  this  call  statement,  the  data  definition  is  verified  and  compiled 
internally. 


6.2.4  Data  Manipulation  Commands  of  MIDAS/R 

Data  manipulation  commands  open,  close,  store,  retrieve,  modify, 
and  delete  data,  rename  a  relation  or  a  data  set,  rename  an  attribute 
and  copy  data  sets  in  a  database.  These  commands  were  not  available  in 
the  RIM  program.  The  function  and  description  of  these  commands  are 
given  in  the  following  paragraphs. 

Open  a  Database. 

CALL  RDDOPN  (NAME,  STAT,  IERR) 

NAME  =  Name  of  the  database 

ST AT  =  Permanent  or  temporary  status  of  the  database 


A  database  closed  earlier  can  be  opened  using  this  command.  A 
database  has  to  be  opened  before  any  operation  on  the  database  is 
performed . 

Close  a  Database. 

CALL  ROBEND  ( IERR) 

IERR  =  Error  code 

A  database  is  closed  using  this  command.  Execution  of  this  command 
transfers  the  system  buffer  data  into  the  database  and  closes  the  file. 

Store  Data  in  a  Relation. 

CALL  RDSPUT  (NAME,  DSNAME,  KROW,  UBUF,  IERR) 

NAME  =  Name  of  the  database 

DSNAME  =  Name  of  a  relation 

KROW  =  Row  number 

UBUF  =  User  buffer  which  contain  data 

IERR  =  Error  code 

Data  can  be  stored  into  a  relation  from  application  program  work 
area  (user  buffer)  by  using  this  command.  Data  is  transfered  from  user 
buffer  to  the  specified  row  of  a  relation.  Tf  more  rows  have  to  be 
stored,  a  FORTRAN  DO  loop  over  the  row  number  in  the  application  program 
will  transfer  all  the  required  rows.  More  details  of  this  command  are 
given  in  the  user's  manual  (Sreekanta  Murthy  and  Arora,  1984). 

Retrieve  Data  from  a  Relation. 

CALL  RDSGET  (NAME,  DSNAME,  KROW,  UBUF,  IERR) 


Data  can  be  retrieved  from  a  relation  into  a  user  buffer  using  this 
command.  Requested  row  of  a  relation  is  transfered  from  a  relation  into 
user  buffer.  FORTRAN  DO  loop  over  the  row  number  is  necessary  if  more 
than  one  row  has  to  be  retrieved.  Data  can  be  retrieved  in  the  same 
order  as  it  was  stored  by  initializing  row  number  as  zero.  Data  of  a 
relation  satisfing  certain  condition  (for  example,  attributes  having 
certain  values)  can  be  retrieved  into  user  buffer.  User  specifies  the 
condition  on  data  values  that  must  be  satisfied  for  retrieval,  by  using 
RDSRUL  command  (explained  later).  The  details  for  various  ways  of  data 
retrieval  is  given  in  the  user's  manual  (Sreekanta  Murthy  and  Arora, 
1984).  Arguments  are  the  same  as  in  RDSPUT. 


Modify  Data  in  a  Relation. 

CALL  RDSMOD  (NAME,  DSNAME,  KROW,  UBUF,  IERR) 

Once  a  database  is  loaded  using  RDSPUT  command,  it  can  be  modified 
by  calling  RDSMOD.  This  routine  modifies  a  row  of  the  relation.  RDSGET 
routine  is  called  before  calling  this  subroutine.  A  row  of  a  relation 
is  retrieved  into  user  buffer  and  this  row  or  a  part  of  the  row  can  be 
modified  and  stored  back  using  the  command.  Arguments  are  the  same  as 
in  RDSPUT. 


Delete  Rows  of  a  Relation. 

CALL  PRWDEL  (NAME,  DSNAME,  KROW,  IERR) 

Rows  of  a  relation  can  be  deleted  using  this  command.  This  is 
useful  in  eliminating  unwanted  values  in  a  relation.  Arguments  are  the 
same  as  in  RDSPUT. 


'no 


Delete  a  Relation. 

CAL'  RDSOEL  (NAME,  DSNAME,  IERR) 

This  command  deletes  a  relation  from  a  database.  Arguments  are  the 
same  as  in  ROSPUT. 

Rename  a  Relation. 

CALL  RDRNAM  (NAME,  OLDNAM,  NEWNAM,  IERR) 


NAME 

=  Name  of  a  database 

OLDNAM 

=  Old  name  of 

the 

rel ation 

NEWNAM 

=  New  name  of 

the 

rel ation 

IERR 

=  Error  code 

An  existing  relation's  name  can  be  changed  to  a  new  name  using  the 
command. 

Rename  an  Attribute. 

CALL  RRNATT  (NAME,  DSNAME,  OLDATT,  NEWATT,  IERR) 

NAME  =  Name  of  a  database 
DSNAME  =  Relation  name 
OLDATT  =  Old  attribute  name 

NEWATT  =  New  attribute  name 

IERR  =  Error  code 

Copy  a  Relation. 

CALL  RDSCPY  (NAME1 ,  NAME 2,  DSNAM1 ,  DSNAM2 ,  IERR)**AM2,  IERR) 

NAME1  =  Name  of  a  database  containing  data 

NAME2  =  Name  of  a  database  where  data  has  to  be  copied 

DSNAM1  =  Relation  name  containing  data 
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DSNAM2  =  Relation  name  to  where  data  has  to  be  copied 
IERR  =  Error  code 

Using  this  command,  data  from  one  relation  can  be  copied  to  another 
relation.  Both  the  database  and  relation  must  have  been  defined  before 
copying  the  data. 


Condition  Specification  for  Retrieval  of  Data. 

CALL  RDSRUL  (NUM,  AT NAM,  COND,  VALUE,  BOOL,  IERR) 


NUM 

= 

Number  of  conditions 

AT  NAM 

= 

A  vector  of 

attribute  names 

COND 

= 

A  vector  of 

logical  operator 

(EQ,  GT, 

VALUE 

= 

A  vector  of 

attribute  values 

BOOL 

= 

A  vector  of 

Boolean  operator 

(AND, OR) 

IERR 

= 

Error  code 

As  mentioned 

in  RDSGET 

command,  data  values  sat 

conditions  can 

be 

retrieved . 

The  conditions 

can  be 

RDSRUL  command.  This  command  must  be  executed  before  calling  RDSGET 
routine.  A  maximum  of  ten  conditions  can  be  specified  at  a  time.  The 
following  example,  illustrates  use  of  this  command. 

Condition  on  a  relation  X: 

Attribute  A*GT*15*3  *AND*  Attribute  B*LT*20*1 
.,se  NUM  -  2;  AT  NAM  ( 1 )  =  'A';  ATNAM(  2)  =  ’  B ' 

CONU(l)  =  *  GT* ;  C0ND(2)  =  *  LT 1  ; 

VALUE ( 1 )  =  15.3;  VALUE(2)  =  20.1; 

600L( 1 )  =  'AND' 
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6.2.5  Interactive  Commands 

MIDAS/R  provides  interactive  support  for  creating,  updating, 
modifying,  and  deleting  a  database.  Interactive  commands  are  general 
and  can  be  used  in  any  application.  The  system  provides  terminal 
prompts  for  the  users  to  respond  with  appropriate  commands.  The 
interactive  session  starts  with  a  display  of  MENU  and  requests  the  user 
to  choose  one  of  the  five  options:  CREATE,  UPDATE,  QUERY,  COMMAND  and 
EXIT.  The  interactive  session  ends  with  an  EXIT  command.  The  detailed 
commands  for  each  of  these  options  are  entered  at  appropriate  instant. 
They  are  given  in  the  following  paragraphs. 

Database  Definition. 

CREATE  XXXX 

Create  command  branches  out  to  interactively  define  a  new 
database.  System  responds  by  requesting  database,  relation  and 
attribute  names,  and  authori zation  access  details.  User  can  supply 
these  data  at  the  prompt.  Details  of  using  this  command  are  given  in 
user's  manual  (Sreekanta  Murthy  and  Arora,  1984). 

Loading  a  Database. 

After  a  database  has  been  successfully  created,  it  may  be  loaded 
before  ending  'create'  session.  for  user  response  ' Y '  for  the  load 
prompt,  the  list  of  existing  relations  that  may  be  loaded  are 
displayed.  The  values  of  attributes  are  entered  corresponding  to  each 
attribute  type. 


Querying  a  Database. 

A  database  defined  and  loaded  as  specified  in  the  previous 
paragraphs  can  be  queried.  Query  will  be  in  the  COMMAND  mode  of 
interactive  session.  There  are  a  number  of  query  commands  which  allow 
users  to  query  a  database.  They  are  described  in  the  following 
paragraphs . 

SELECT.  Select  command  is  used  for  displaying  data  of  a 
relation.  Options  to  display  all  or  selected  attributes  are 
available.  Several  possible  select  options  are  given  below: 

SELECT  ALL  FROM  [relation  name] 

SELECT  [attribute  name]  FROM  [relation  name] 

SELECT  ALL  FROM  [relation  name]  WHERE  [attribute  name]  [condition] 
[values]  [AND/OR]  ... 

continuation  dots  indicate  that  upto  ten  conditions  can  be  specified. 
The  conditions  have  to  the  one  of  the  following 

(a)  [attribute  name]  [EQj NE | GT j LT | LE | GE]  [value] 

(b)  [attribute  name]  [EQ| NE|GT|LT|LE|GE|  [attribute  name] 

(c)  ROWS  [ E Q | NE | LT | LE | GE]  [row  number] 

LISTREL.  List  command  allows  user  to  display  information  about 
relations  and  attributes.  The  following  options  are  available  in 
LISTREL  command. 

LISTREL 

LISTREL  [relation  name] 


LISTREL  ALL 
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CHANGE.  Data  values  in  a  relation  can  be  changed  using  this 
command.  The  following  options  are  available 

CHANGE  [attribute]  TO  [value]  IN  [relation  name] 

CHANGE  [attribute]  TO  [VALUE]  IN  [relation  name] 

WHERE  ... 


DELETE.  This  command  can  be  used  to  delete  selected  rows  in  a 
rel ation : 

DELETE  ROWS  FROM  [relation  name]  WHERE  ... 


RENAME.  Attributes  and  relations  can  be  renamed  using  this 


command : 


RENAME  [attribute]  TO  [attribute]  In  [relation  name] 
RENAME  RELATION  [relation  name]  TO  [relation  name] 


REMOVE.  A  relation  can  be  deleted  from  database  definition  using 
REMOVE  command: 

REMOVE  [relation  name] 


PROJECT.  This  is  a  relational  algebra  command.  The  function  of 
PROJECT  is  to  create  a  new  relation  as  a  subset  of  an  existing 
relfcion.  The  new  relation  is  created  fron  an  existing  relation  by 
removing  attribues,  rows  or  both. 

PROJECT  [relation  name]  FROM  [relation  name] 

USING  [attribute]  [  attribute]  ...  WHERE  ... 


VtVi 


JOIN.  The  purpose  of  JOIN  command  is  to  combine  two  relations 
based  on  specific  attributes  from  each  row.  The  result  of  JOIN  command 
is  a  third  relation  containing  all  the  specified  attributes  from  both 


the  relations. 

JOIN  [relation  name]  USING  [attribute  name] 

WITH  [relation  name]  USING  [attribute  name] 

FORMING  [relation  name]  WHERE  ... 

INPUT.  This  command  assigns  input  file  for  MIDAS/R  to  read  data 

without  user  interaction 
INPUT  [file  name] 

OUTPUT.  The  output  of  execution  may  be  placed  in  a  given  file 
name.  If  file  name  is  TERMINAL,  then  all  messages  and  data  are 
displayed  at  the  terminal: 

OUTPUT  [file  name] 

EXIT/QUIT.  The  system  buffer  data  is  transfered  to  database  files 
and  database  is  closed. 

HELP.  User  can  obtain  a  description  of  the  available  commands  on 
the  termi nal  . 
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6.2.6  System  Design  of  MIDAS/R 

Database  structure  of  MIDAS/R  is  same  as  the  RIM  database, 


Each 


database  consists  of  three  files.  The  first  file  stores  relation  and 
attribute  names  and  their  details.  The  second  file  contains  the  actual 


data.  The  third  file  contains  pointers  to  keyed  attributes.  The 
program  is  written  in  F0RTRAN77.  It  consists  of  a  number  of  subroutines 
having  well  defined  functions.  Functions  of  these  subroutines  can  be 
generally  classified  into  (i)  command  processors,  (ii)  input-output 
processor,  (iii)  file  definition  and  initialization  routines,  (iv) 
memory  management  routines,  (v)  addressing  and  searching  routines,  (vi) 
conditional  clause  and  rule  processing  routines,  and  (vii)  security 
routines . 

Extensions  to  RIM  program  are  made  to  include  dynamic  data 
definition  facility.  The  command  processing  routines  were  changed  to 
incorporate  this  facility.  Any  new  definition  of  a  relation  or  an 
attribute  during  execution  of  a  program  is  stored  in  a  file  for 
processing.  Command  processing  routines  are  used  to  verify  syntax  of 
the  relation  and  attribute  definition.  Later,  the  data  definitions  are 
compiled  and  stored  in  the  first  file  of  the  database. 

Modification  of  the  application  interface  commands  are  made  to 
simplify  the  data  storage,  retrieval  and  modification  of  data.  The 
original  set  of  conventional  data  manipulation  commands  in  RIM  were 
found  to  be  tedious  to  use  in  applications  such  as  finite  element 
analysis  programs.  This  was  because,  even  for  a  simple  retrieval  of 
data  at  least  two  or  three  DML  calls  had  to  be  made.  In  the  MIUAS/R 
program,  such  storage  and  retrieval  of  data  is  made  generally  using  one 
call  statement. 

MIDAS/R  data  manipulation  commands  use  relation  and  database  names 
for  data  manipulation  operations,  whereas  in  RIM,  users  are  required  to 


assign  integer  numbers  to  refer  to  predefined  relations  of  a  database 


that  are  to  be  manipulated.  The  use  of  database  and  relation  names  in 


data  manipulation  commands  reduces  programming  errors  on  the  part  of 


users  which  otherwise  may  cause  reference  to  a  wrong  relation.  Also,  by 


specifying  database  and  relation  names,  user  is  allowed  to  refer  to  a 


relation  in  another  database  directly  without  using  commands  for  opening 


and  closing  of  database  files.  Arguments  of  data  manipulation  commands 


of  M I  DAS./  R  for  storage,  retrieval  and  modification  have  provisions  for 


specification  of  row  number  of  a  relation.  The  routines  for  storage  and 


retrieval  internally  use  the  row  numbers  to  transfer  users  data  to 


specified  locations  in  a  relation.  This  provision  of  row  number 


specification  in  the  argument  has  facilitated  in  simplifying  application 


program  logic. 


To  improve  the  performance  of  MIDAS/R,  an  additional  memory 


management  interface  is  adde'.  The  memory  management  scheme  allocates 


available  memory  into  a  number  of  pages  of  fixed  size.  ‘Least  recently 


used1  page  replacement  scheme  is  used  for  replacement  of  pages.  The 


page  size  and  number  of  pages  can  be  altered  by  changing  certain 


parameters  in  the  system, 


6.2.7  Limitations  of  MIDAS/R 


'here  are  a  numoer  of  limitations  of  the  MIDAS/R  program.  One  of 


the  limitations  is  tnat  program  does  not  have  capability  to  operate  on  a 


number  of  databases  simultaneously.  Secondly,  the  maximum  size  of  a  row 


in  a  relation  cannot  exceed  1024  words.  it  one  size  of  a  row  exceeds 
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this  limit,  user  should  split  the  row  suitably  and  operate  on  portions 
of  a  row  at  a  time.  Also,  the  number  of  attributes  in  a  relation  cannot 
exceed  20.  The  memory  management  scheme  has  fixed  block  size.  User  has 
no  control  over  the  block  size  to  tune  it  according  to  the  relation 
size.  At  present  only  five  relations  can  be  operated  at  a  time  in  the 
system  buffer  as  only  five  pointers  to  current  relations  are  maintained 
by  the  DBMS.  Detailed  evaluation  of  efficiency  of  MIDAS/R  is  given  in 
Chapter  IX. 


to. 3  Description  of  MIDAS/N 

MIDAS/N  is  a  database  management  system  (Shyy,  1985)  to  support 
data  organization  of  numerical  computations.  MIDAS/N  is  implemented 
based  on  numerical  data  model.  It  has  data  definition  and  data 
manipulation  commands  to  define  large  order  matrix  data  and  manipulate 
them.  Large  matrices  such  as  rectangular,  square,  upper  triangular, 
lower  triangular  and  hyper  matrices  can  be  defined  in  the  database. 
Matrix  data  can  be  arranged  in  row,  column,  or  submatrix  order.  Data 
can  be  short  integer,  long  integer,  real,  double-precision  and  character 
types.  Data  mainpulation  commands  of  MIDAS/N  can  store,  retrieve, 
modify  and  delete  matrices.  Data  can  be  accessed  in  row  column  or 
submatrix  order.  Also  individual  data  elements  of  a  matrix  can  be 
accessed.  Database  security  is  provided  through  a  password  access. 
Error  recovery  mechanisms  are  available. 


MIDAS/N  has  capability  to  create  a  number  of  databases,  upto  a 
maximum  of  20  in  the  current  implementation.  These  databases  can  be 


accessed  simultaneously.  The  databases  can  be  permanent  or  temporary. 
A  database  can  store  data  of  a  number  of  matrices,  upto  a  maximum  of 
20.  The  size  of  a  database  and  a  matrix  is  unlimited,  but  only  depends 
on  the  availability  of  disk  space.  Databases  can  be  organized  at  a 
number  of  hierarchical  levels  and  can  be  accessed  using  a  path  name. 
Databases  and  matrices  are  identified  by  a  unique  name. 

In  MIDAS/N,  the  available  memory  (called  the  buffer)  is  divided 
into  pages.  Data  set  is  also  divided  into  pages  of  the  same  size  when 
it  is  defined  or  transferred  into  the  memory  buffer.  MIDAS/N  handles 
all  access  requests  and  transactions  against  data  sets.  Each 
transaction  is  in  terms  of  pages.  Once  part  of  a  data  set  is  requested, 
some  pages  must  be  assigned  to  it.  When  there  is  no  free  page,  some 
page  must  be  freed.  Page  replacement  strategy  decides  the  page  to  be 
freed.  MIDAS/N  chooses  the  'least  recently  used'  page  for 
replacement.  For  handling  transactions,  information  about  data  sets  and 
page  usage  must  be  kept  and  managed.  Information  about  data  set  is 

stored  in  the  'data  set  information'  table.  Information  about  page 
usage  is  stored  in  the  'memory  buffer  information'  table.  Page  size  and 
number  of  pages  can  be  altered  by  changing  certain  parameters  in  the 

system. 

The  MIDAS/N  system  maintains  an  index  table  to  provide  address  of 
stored  records.  Index  table  provides  a  pointer  to  the  data  definition 
block  which  contains  details  of  a  data  set  such  as  name,  type,  order, 
and  size.  Data  definition  block  is  stored  at  the  beginning  of  actual 

data  in  a  file.  Data  set  is  mapped  on  to  physical  storage  space  in  a 

linear  address  sequence. 


MIDAS/ N  has  been  evaluated  for  solving  equations  using  skyline 
storage  scheme  (Shyy,  1985).  The  efficiency  of  MIDAS/N  will  be  compared 
with  that  of  MIDAS/R  in  solving  large  equations.  The  results  are  given 
in  Chapter  9. 


A  DESIGN  OF  DATABASE  FOR  STRUCTURAL 
ANALYSIS  AND  OPTIMIZATION  DATA 


7.1  Introductory  Remarks 

A  database  is  designed  for  finite  element  analysis  and  structural 
optimization  computation  and  its  details  are  given  in  this  chapter. 
Methodology  developed  in  Chapter  4  is  used  in  designing  the  database. 
The  database  design  is  carried  out  in  three  phases.  In  the  first  phase, 
a  conceptual  database  is  designed  to  provide  a  theoretical  basis  for 
organizing  finite  element  analysis  and  structural  optimization  data. 
The  design  of  the  conceptual  data  model  is  given  in  Section  7.3.  In  the 
second  phase,  a  generalized  internal  model  is  designed  which  is  used 
later  to  implement  a  database  for  structural  design  optimization  program 
discussed  in  the  next  chapter.  The  design  of  the  internal  model  is 
given  in  Section  7.4.  In  Section  7.5,  some  relations  are  suggested  to 
form  an  external  data  model.  Finally,  the  methodology  used  in  designing 
the  database  is  evaluated, 

7.2  Identification  of  Data  Used  in  Finite 
Element  Analysis  and  Structural 
Design  Optimizatfon 

Database  design  is  initiated  by  identifying  data  required  for 
finite  element  analysis  and  optimal  structural  design.  In  Sections  2.2 
and  2.5,  we  have  already  described  in  detail  the  data  used  in  structural 


analysis  and  optimization.  Here,  they  are  identified  again  from  the 


database  design  point  of  view.  For  the  design  of  a  conceptual  data 
model,  we  need  to  identify  entities,  attributes,  domains  and  entity 
keys.  In  the  following  subsections,  a  list  of  entities,  entity  keys, 
and  domains  of  data  are  given. 

7.2.1  A  List  of  Entities  of  Analysis 
and  Design  Data 

The  following  entities  are  identified  from  the  data  used  in  finite 
element  analysis  and  optimal  design  computations  (see  Sections  2.2  and 
2.5) : 

1.  Structure 

2.  Substructure 

3.  Element 

4.  Node 

5.  Material 

6.  Element  type 

7.  Material  type 

8.  Cross-section  type 

9.  Degree  of  freedom 

10.  Load  case 

11.  Design  Group 

12.  Design  Variable 

13.  Global  constraint 

14.  Element  constraint 

15.  Node  constraint 


16.  Structure  constraint 


17.  Mode 

18.  Matrix  name 

19.  Vector  name 

20.  Constraint  type 

21.  Load  type 

22.  Member 

The  following  entity  keys  are  identified.  Note  that  an  entity  key 
uniquely  identifies  an  entity. 


1.  Structure  number  (or  name)  S# 

2.  Substructure  number  SUBSTR# 

3.  Element  number  E# 

4.  Node  number  N# 

5.  Material  number  M# 

6.  Element  type  number  (or  name)  ELTVP 

7.  Material  type  number  (or  name)  MTTYP 

3.  Cross-section  type  number  (or  name)  CSTYP 

9.  Degree  of  freedom  number  DOF# 

10.  Load  case  number  LC# 

11.  Design  group  number  DG# 

12.  Design  variable  number  D# 

13.  Global  constraint  number  GC# 

14.  Element  constraint  number  EC# 

15.  Nodal  constraint  number  NC# 


16. 

Structure  constraint  number 

SC# 

17. 

Mode  number 

MODE# 

18. 

Matrix  name 

MN 

19. 

Vector  name 

VN 

20. 

Constraint  type 

CTTYP 

21. 

Load  type 

LDTYP 

22. 

Member 

ME# 

7.2.2  A  List  of  Domains  of  Analysis 
and  Design  Data 

The  following  domains  are  identified: 

1.  Assembled  structure  level  matrices;  e.g.,  K,  M,  C  STRMAT 

2.  Assembled  structure  level  vectors;  e.g.,  P,  U  STRVEC 

3.  Structure  level  parameters,  indices,  flags,  etc.  STRPAR 

e.g..  No.  of  substructures.  No.  of  load  cases 

4.  Assembled  substructure  level  matrices  SUBMAT 

e.g . ,  K-j  y ,  Kfci ,  b ^ 

5.  Assembled  substructure  level  vectors;  e.g.,  SUBVEC 

6.  Substructure  level  parameters,  indices,  flags,  etc.  SUBPAR 

e.g..  No.  of  elements.  No.  of  nodes 

7.  Element  level  matrices;  e.g.,  1C,  Mg  ELMAT 

3Ke 

8.  Element  level  vectors  e.g.,  oQ,  Ge»  -gg-  ELVEC 

9.  Element  level  parameters,  indices,  flags,  etc.  ELPAR 

e.g..  Nonlinearity  index,  damage  flag 


10.  Node  related  vectors;  e.g.,  boundary  condition  codes  NODVEC 
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11.  Node  related  parameters,  indices,  flags,  etc.  NODPAR 

e.g.,  coordinate,  temperature 

12.  Material  property  tables  MATTAB 

e.g..  Nonlinear  material  property  tables 

13.  Material  property  vectors  MATVEC 

e.g.,  stress  limit  vector 

14.  Material  property  parameters  MATPAR 

e.g..  Density,  Young's  Modulus 

15.  Vectors  associated  with  degree  of  freedom  DOFVEC 

e.g.,  velocity  at  specified  set  of  time  points 

16.  Parameters,  indices,  flags  associated  with  DOFPAR 

degrees  of  freedom;  e.g..  Prescribed  displacement, 
constraint  values 

17.  Vectors  associated  with  a  design  group  DESVEC 

e.g..  Vector  of  element  numbers 

18.  Parameters  associated  with  a  design  group  DESPAR 

e.g.,  fixed  design  flag 

19.  Vectors  associated  0  th  a  design  variable  DEVVEC 

e.g.,  upper  bound,  lower  bound,  current  value 

20.  Parameters  associated  with  a  design  variable  DEVPAR 

e.g.,  fixed  design  index 

21.  Matrices  associated  with  global  constraints;  e.g.,  GLCMAT 

22.  Vectors  associated  with  global  constraints;  e.g.,  ip  GLCVEC 


23.  Parameters,  indices,  flays  associated  with 

global  constraint;  e.g.,  active  constraint  number 


GLCPAR 


24.  Matrices  associated  with  element  level  constraints 


ELCMAT 


e*9*’  IB" 

25.  Vectors  associated  with  element  level  constraints 
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ELCVEC 


26.  Parameters  associated  with  element  level  constraints  ELCPAR 
e.g.,  Normalized  element  constraint  value, 
ip  =  ae/aa  -  1 


27.  Vectors  associated  with  node  constraints 


NDCVEC 


e.g.,  ip  =  z./z.  -  1  j  =  1,  no.  of  dof/node 

J  J 

28.  Vectors  associated  with  structure  level  constraints 
dKz  3M  v 

e.g.,  ip-  -  ^  IB  z) 


STCVEC 


29.  Parameters  associated  with  structure  level  constraints  STCPAR 

e.g.,  ip  =  c/c0  -  1 

30.  Vectors  associated  with  frequency/buckling;  e.g.,  y  MODVEC 


31.  Parameters  associated  with  frequency/buckling 


MODPAR 


e.g.,  X 

32.  Names  in  characters 

e.g.,  matrix  name,  vector  name,  element  name 

33.  Numbers  in  integers  values 

e.g.,  element  numbers,  node  numbers 

34.  Numbers  in  real  values;  density,  temperature 

35.  Numbers  in  double  precision  values;  e.g.,  frequency 
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7.3  Design  of  a  Conceptual  Data  Model 


Following  the  methodology,  a  rough  conceptual  data  model  is 
designed  by  associating  entities  with  domains.  Details  of  this  model 
are  given  in  Section  7.3.1.  Later,  this  model  is  refined  by  introducing 
additional  relations  derived  from  transitive  closure.  Details  of  this 
step  are  given  in  Section  7.3.2.  From  the  obtained  set  of  elementary 
relations  a  set  of  semantically  meaningful  relations  are  selected.  A 
refined  conceptual  data  model  is  finally  obtained  by  removing  redundant 
elementary  relations. 


7.3.1  Elementary  Relations  and 
Diagraph  Representation 

By  associating  the  entities  given  in  Section  7.2.1  with  the  domains 
listed  in  Section  7.2.2,  we  get  a  set  of  relations.  For  example,  by 
associating  entity  structure  with  domains  STRMAT,  STRVEC,  and  STRPAR  and 
with  entities  MN  and  VC,  we  get  the  relation: 

R1  (S,  MN,  VN,  STRMAT,  STRVEC,  STRPAR) 

Note  that  S,  MN,  VN,  STRMAT,  STRVEC,  and  STRPAR  from  attributes  of  this 
relation.  Entities  MN  and  VN  are  assigned  with  entity  S  to  identify  the 
actual  matrix  and  vector  associated  with  STRMAT  and  STRVEC.  It  is 
possible  to  further  derive  several  attributes  from  domains  STRMAT, 
STRVEC  and  STRPAR  to  provide  role  identi fication  in  relation  Rl.  For 
example,  attributes  K  and  M  can  be  derived  to  provide  role 
identification  for  domain  STRMAT.  But,  at  this  stage  of  database 
design,  such  details  are  omitted  to  maintain  generality  of  the 


conceptual  data  model 


Details  are  introduced  at  the  actual 


implementation  stage  of  database  design.  Therefore,  STRMAT  is 
considered  here  as  a  generalized  attribute  which  actually  represents  K, 

H,  C,  etc. 

Reducing  this  relation  to  several  elementary  relation  we  get 
STRUCTURE  -  MATRIX  (S #,  MN,  STRMAT) 

STRUCTURE  -  VECTOR  (S#,  VN,  STRVEC) 

STRUCTURE  -  PARAMETER  (S#,  STRPAR) 

Here,  the  attribute  STRMAT  is  ful ly-functional ly  dependent  on  S#  and  MN. 

A  diagraph  representation  of  the  association  between  entity 
structure  and  various  attributes  (for  example  -  assembled  stiffness 
matrix,  mass  matrix)  derived  from  domain  STRMAT  and  STRVEC  is  shown  in 

Fig.  7.3.1.  Similarly  other  elementary  relations  are  derived  and  they 

are  listed  in  Fig.  7.3.2.  The  list  also  includes  the  relations  between 
entities  themselves.  This  list  of  elementary  relations  forms  a  rough 
conceptual  data  model  to  represent  finite  element  analysis  and 
structural  design  optimization  data. 

7.3.2  Deriving  Additional  Relations 

An  initial  connectivity  matrix  representing  the  elementary 
relations  of  Fig.  7.3.2  is  made.  This  is  shown  in  Fig.  7.3.3.  Using 
the  algorithm  of  Appendix  1,  additional  relations  are  derived.  The 
algorithm  uses  the  initial  connectivity  matrix  and  produces  a  final 

connectivity  matrix  shown  in  Fig.  7.3.4.  From  this  matrix,  additional 

elementary  relations  formed  are  identified.  Several  hundred  new 
relations  are  obtained  as  indicated  in  Fig.  7.3.S.  These  additional 
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Figure  7.3.2  Initial  List  of  Elementary  Relations 
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relations  together  with  original  elementary  relations  are  shown  in  the 
diagraph  of  Fig.  7.3.6.  Derived  relations  are  shown  in  dotted  lines  in 
the  figure. 

7.3.3  Selecting  Elementary  Relations 
to  Form  a  Conceptual  Data  Model 

Now,  we  have  uncovered  all  possible  association  between  data  used 
in  the  analysis  and  design  computation.  From  the  diagraph  of  Fig. 
7.3.6,  we  see  that  several  paths  for  accessing  a  particular  data  are 
available.  Out  of  these  paths,  suitable  ones  are  selected  according  to 
our  needs  in  the  finite  element  analysis  and  optimization 
computations.  The  following  paths  are  identified  for  some  important 
data,  and  paths  selected  are  discussed. 

Material  Property  Data.  Available  paths  are  (a)  S#  +  SUBSTR#  -*• 
E#  ♦  M#  *  MATPAR,  (b)  S#  ♦  SUBSTR#  ->•  MM  *  MATPAR,  and  (c)  S#  +  M# 
MATPAR.  Paths  (b)  and  (c)  are  generally  not  useful  unless  all  elements 
in  a  substructure  or  structure  use  the  same  material  property.  Path  (a) 
identifies  material  property  for  each  element  and  therefore  it  is 
sel ected . 

Cross-Section  Data.  Available  paths  are  (a)  S#  SUBSTR#  *  E#  + 
CSTi'P  -  CSDET,  (b)  S#  *  SUBSTR#  *  ELPAR ,  and  (c)  S#  ♦  ELPAR .  Paths  (b) 
and  ' c)  are  meaningless.  Path  (a)  is  appropriate  to  find  cross- 
sectional  property  of  a  particular  element. 

Degree  of  Freedom  Data.  Available  paths  are  (a)  S#  >  SUBSTR#  -*• 
E*  >  N#  -  DOF#,  (b)  S#  >  SUBSTR#  >  E#  ►  DOF#,  (c)  S#  >  SUBSTR^  >  N#  > 


osure  for  the  Elementary  Relations  (Partial 


DOF?,  (d),  S#  *  E#  +  DOF?,  and  (e)  S#  +  DOF#.  Path  (a)  is  useful  if 
nodal  degrees  of  freedom  are  available.  Path  (b)  is  useful  for  assembly 


of  stiffness  matrix.  Path  (c)  is  useful  for  assembly  of  global 

matrices.  Paths  (d)  and  (f)  are  appropriate  when  substructures  are  not 
used.  Paths  (a),  (b)  and  (c)  are  selected. 

Coordinate  Data.  The  coordinate  data  belongs  to  domain  NODPAR 
and/or  ELPAR.  Available  path  to  access  NODPAR  are  (a)  S#  +  SUBSTR#  > 
N#  ►  NODPAR  (coordinates) ,  (b)  S#  >  SUBSTR#  +  E#  >  ELMVEC  (coordinates) , 
(c)  S*  >  NODPAR  -*■  E#  >  N#  *  NODPAR,  (d)  S#  +  ELPAR,  and  (e) 

S-  >  NODPAR.  Paths  (d)  and  (e)  are  meaningless.  Path  (a)  just  gives 
nodal  coordinates  of  a  substructure  which  may  not  be  directly  useful. 
Path  (b)  gives  element  coordinates  which  are  useful  for  element 
stiffness  computation.  Path  (c)  is  longer  than  path  (b)  to  know 

coordinates  of  an  element. 

Design  Variable  Data.  Available  path  to  access  data  such  as  design 
value,  upper  bound,  lower  bound  associated  with  D#  are  (a)  S#  -*•  SUBSTR# 
E#  >  OG*  *  D#  >  DEVPAR,  (b)  S#  ►  SUBSTR#  >  DG#  ♦  D#  *  DEVPAR,  (c)  S#  + 
SUBSTR*  >  D*  -«■  DEVPAR,  and  (d)  S#  *  D#  *  DEVPAR.  Path  (a)  is  useful  to 
know  the  values  of  cross-sectional  geometry  of  elements.  Path  (b) 
identifies  the  design  values  for  each  desiyn  yroup.  Design  variables  of 
a  substructure  or  structure  are  obtained  by  paths  (c)  and  (d).  All 
these  paths  are  usea  in  computation. 

Displacement  Data.  To  access  displacements  data  (DOFPAR),  the 
available  paths  are  (a)  S*  +  SUBSTR#  *-  E#  >  N#  +  DOF#  ►  DOFPAR,  (b)  S# 
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-*■  SUBSTR#  ♦  E#  ♦  DOF#  ->•  DOF  PAR,  (c)  S#  -  SUBSTR#  +  N#  +  DOF#  •*  DOFPAR, 
(d)  S#  ♦  SUBSTR#  -*•  DOF#  ♦  DOFPAR,  and  (e)  S#  >  DOF#  *  DOFPAR.  Path  (a) 
is  longest  to  access  displacement  data.  Path  (b)  is  useful  to  know 
displacements  of  elements.  Path  (c)  gives  displacements  of  nodes. 
Paths  (d)  and  (e)  give  displacement  of  a  substructure  or  structure. 
These  paths  are  used  in  computation  and  are  retained. 

Similar  arguments  are  made  in  selecting  various  paths  needed  for 
computations.  Each  of  the  paths  represents  a  set  of  elementary 
relations  representing  the  conceptual  data  model  for  finite  element 
analysis  and  structural  design  optimization. 

7.4  Design  of  Internal  Data  Model 

An  internal  data  model  is  designed  for  storing  data  of  finite 
element  analysis  and  structural  design  optimization  data.  The 
methodology  developed  in  Chapter  4  is  used  to  design  this  data  model. 
The  design  of  the  internal  data  model  is  initiated  by  identifying  the 
data  needs  of  various  computations  listed  in  Section  2.3.  The  data  so 
identified  are  arranged  in  a  number  of  relations.  These  relations  are 
refined  by  the  normal i zation  procedure.  By  this  procedure,  a  new  set  of 
relations  are  obtained  which  are  later  checked  for  consistency  with  the 
conceptual  (theoretical)  data  model.  Note  that  this  internal  data  model 
is  used  for  implementing  the  database  of  structural  design  optimization 
program.  Details  of  the  internal  data  model  design  are  given  in 
Sections  7.4.1  and  7.4.2. 


7.4.1  Data  Needed  in  Computation  Process 

The  data  needed  and  generated  in  various  steps  of  analysis  and 
design  computation  (see  Section  2.3)  are  identified.  They  are  arranged 
in  a  number  of  relations. 

Element  Level  Computation. 

R1  (E#,  S#,  SUBSTR#,  N#,  M#,  ELTYP,  MATTYP,  CSTTYP,  LC#,  MN,  VN,  LDTYP, 
ELMAT,  ELVEC,  ELPAR,  NODVEC,  NODPAR,  MATTAB,  MATVEC,  MATPAR) 


Substructure  Level  Computation. 

R2  (SUBSTR#,  S#,  E#,  N#,  DOF#,  LC#,  MODE#,  MN,  VN,  LDTYP,  SUBMAT, 

SUBVEC,  SUBPAR,  ELMAT,  ELVEC,  ELPAR,  NODVEC,  NODPAR,  DOFVEC,  DOFPAR , 
MODVEC ,  MODPAR) 


Structure  Level  Computation. 

R3  (S#,  SUBSTR#,  E#,  N#,  DOF#,  LC#,  MODE#,  MN,  VN,  LDTYP,  STRMAT , 

STRVEC,  STRPAR ,  SUBMAT,  SUBVEC,  SUBPAR,  ELMAT,  ELVEC,  ELPAR,  NODVEC, 
NODPAR,  DOFVEC,  DOFPAR,  MODVEC,  MODPAR) 


Recovery  of  Element  Response. 

R4  (E#,  S#,  SUBSTR#,  N#,  M# ,  ELTYP.,  MATTYP,  CSTYP,  LC#,  MN,  VN,  LDTYP, 
STRVEC,  STRPAR,  SUBVEC,  SUBPAR,  ELMAT,  ELVEC,  ELPAR,  NODVEC,  NODPAR, 
MATTAB,  MATVEC,  DOFVEC,  DOFPAR,  MODVEC,  MODPAR) 


Design  Problem  Formulation. 


R5  (D»,  S= ,  SUBSTR#,  E# ,  N# ,  M#,  ELTYP,  MATTYP,  CSTYP,  DG#,  MN,  VN,  ME#, 
STRPAR,  SUBPAR,  ELVEC,  ELPAR,  NODVEC,  NODPAR,  MATTAB,  MATVEC,  DESVEC, 
DESPAR,  DEVVEC ,  DEVPAR) 


R6  (GC* ,  S*,  SUBSTR? ,  E# ,  N#.  M# ,  ELTYP,  MATTYP,  CSTYP, 
D#,  EC#,  NC#,  SC#,  MODE#,  MN,  VN,  CTTYPE,  LDTYP,  ME#, 
ELVEC,  ELPAR,  NODVEC,  NODPAR,  DOFVEC,  DOFPAR,  DESVEC, 
DEVPAR,  GLCVEC,  GLCPAR ,  ELCVEC,  ELCPAR,  NDCVEC,  STCVEC, 

MODPAR) 


DOF#,  LC#,  DG#, 
STRPAR,  SUBPAR, 
DESPAR,  DEVVEC, 
STCPAR,  MODVEC, 


Constraint  Checks. 

R7  (GC#,  S#,  SUBSTR#,  EC#,  NC#,  SC#,  GLCPAR) 

Design  Sensitivity  Analysis. 

R8  (GC#,  S#,  SUBSTR#,  E#,  N#,  M#,  ELTTYP,  MATTYP,  CSTYP,  DOF#,  LC#,  DG#, 
D#,  EC#,  NC#,  SC#,  MODE#,  MN,  VN,  CTTYP,  LDTYP,  ME#,  STRMAT. ,  STRVEC, 
STRPAR.,  SUBMAT,  SUBVEC,  SUBPAR.,  ELMAT,  ELVEC,  ELPAR,  NODVEC,  NODPAR, 
MATTAB,  MATVEC,  DOFVEC,  DOFPAR,  DESVEC,  DESPAR,  DEVVEC,  DEVPAR,  GLCMAT, 
GLCVEC ,  GLCPAR,  ELCMAT,  ELCVEC,  ELCPAR,  NDCVEC,  STCVEC,  STCPAR,  MODVEC, 
MODPAR) 

7.4.2  Relations  and  Matrices  for 
Internal  Data  Model 

The  relations  RI  to  R8  formed  in  Section  7.4.1  are  not  in  normal 
form.  But  they  contain  all  the  relevant  data  needed  for  the 

computation.  Therefore,  they  are  normalized  using  the  methodology 
developed  in  Chapter  4.  The  normalized  relations  are  shown  in  Fig. 

7.4.2.  These  relations  are  consistent  with  the  conceptual  model 

designed  in  Section  7.3.  The  relations  shown  in  Fig.  7.4.2  are  grouped 
into  several  categories  to  identify  them  easily.  The  groups  are  (i) 

Element,  (ii)  Node,  (iii)  Material,  (iv)  Element  Type,  (v)  Nodal 
Constraint,  (vi)  Element  Constraint,  (vii)  Structure  Constraint,  (viii) 
Global  Constraint,  (ix)  Mode,  (x)  Design  Variable,  (xi)  Matrix,  and 
(xii)  Vector.  Since,  many  of  the  relations  are  required  independently 
for  each  substructure,  substructure  numbers  are  assigned  to  the 

relations  to  identify  them. 

The  matrices  used  in  the  computation  are  organized  using  numerical 
data  model.  The  internal  model  for  numerical  data  is  shown  in  Fig. 

7.4.3.  The  model  uses  hypermatrix  scheme  to  organize  large  matrices 
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assembled  at  substructure  and  structure  level.  Skyline  and  banded 
scheme  for  large  matrix  data  organization  are  also  shown  in  Fig. 
7.4.3.  Varicus  structure  level  and  substructure  level  matrices  are 
shown  in  Fig.  7.4.2. 


7.5  An  External  Data  Model  Design 

Building  a  complete  set  of  relations  forming  an  external  data  model 
is  entirely  dependent  on  the  requi reinents  of  new  applications  that  will 
use  the  database.  Considering  all  possible  new  applications  and  their 
requirements  are  beyound  the  scope  of  this  study.  Hence,  no  further 
attempt  is  made  here  to  derive  all  possible  relations  for  an  external 
data  model.  However,  some  specific  examples  are  given  below  to  describe 
external  model  design. 

Suppose,  a  new  application  needs  the  data  of  element  degrees  of 
freedom  numbers.  Assuming  that  this  data  is  not  already  stored  in  the 
database,  a  new  relation  is  constructed  containing  the  required  data. 
In  this  case,  a  new  relation  ELMDOF  is  derived  as  shown  in  Fig.  7.5.1 
from  existing  relations  EIMVEC  and  NODVEC.  Similarly,  if  another 
application  needs  the  element  connectivity  data  separately  for  each  type 
of  element,  then  relations  BEAM,  TRIANG,  and  QUADRAL  are  derived  as 
snown  in  Fig.  7.5.1. 

7.6  Evaluation  of  Database  Design  Methodology 

Database  design  methodology  developed  in  Chapter  4,  is  found  to  be 
extremely  useful  in  designing  the  database  given  in  Sections  7.2  to 
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Figure  7.5.1  Relations  for  External  Model 


7.5.  The  methodology  is  used  to  the  design  the  conceptual  data  model 
for  finite  element  analysis  and  structural  optimization  data.  It  uses 
information  about  entities,  domains,  functional  dependencies  in  data  to 
obtain  the  data  model.  The  conceptual  data  model  enabled  us  to 
understand  the  inherent  nature  of  finite  element  analysis  and  structural 
design  optimization  data.  Thus,  we  are  able  to  associate  different  data 
items  depending  on  their  characteristics.  Many  associations  of  data 
items  which  cannot  be  readily  identified  by  the  database  designer  was 
brought  out  by  the  use  of  transitive  closure  principle  and  connectivity 
matrix  procedure.  Thus,  the  methodology  to  develop  the  conceptual  data 
model  for  finite  element  analysis  and  design  optimization  data  is  found 
useful.  This  conceptual  data  model  serves  as  a  theoretical  database  to 
check  the  database  that  is  designed  using  the  internal  data  model. 

However,  in  using  the  methodology  to  design  the  conceptual  data 
model,  some  difficulties  are  encountered.  One  of  the  main  difficulties 
is  in  the  proper  identification  of  entities  and  domains  of  finite 
element  analysis  and  design  optimization  data.  For  example,  data  of 
element  type  --  is  it  a  separate  entity  or  just  a  property  of  entity 
element?  Similarly,  data  of  cross-section  type  faces  the  same 
problem.  The  methodology  of  database  design  did  not  suggest  suitable 
schemes  to  classify  such  kind  of  data.  Another  problem  was  to  what 
extent  the  generality,  of  domain  identification  should  be  maintained. 
At  one  extreme,  domains  may  be  identified  as  integer  numbers,  real 
'umbers,  characters,  vectors  and  matrices.  At  another  extreme,  domains 
t  iy  be  identified  in  great  detail,  for  example: 


a  set  of  element 


numbers  greater  than  1  and  less  than  100,  a  set  of  stiffness  matrices  of 
size  nxn;  a  set  of  load  vectors  of  size  n;  a  set  of  truss  element  member 
connectivity  vector.  Too  much  generality  will  not  bring  out  clear 
identi  fication  of  character!' sties  of  finite  element  analysis  and  design 
optimization  data.  Detailed  approach  in  identifying  domains  will  lead 
to  confusion  and  tedious  database  design  process.  Further,  in  selecting 
a  suitable  set  of  elementary  relations  from  the  transitive  closure,  some 
difficulties  are  encountered.  Since,  there  exists  several  path  to 
access  data,  selection  of  a  suitable  path  depends  on  the  judgement  of 
database  designer.  Use  of  processing  sequence  has  helped  in  resolving 
selection  of  elementary  relations  to  some  extent. 

The  methodology  to  design  an  internal  data  model  for  finite  element 
analysis  and  structural  optimization  data  has  provided  us  with  a  tool  to 
design  a  database  and  implement  it  using  a  DBMS.  The  methodology  is 
found  very  useful  in  separating  general  tabular  type  of  data  and  matrix 
data  used  in  analysis  and  optimization  computations.  The  use  of 
normalization  procedures  in  internal  database  design  has  enabled  us  to 
obtain  a  set  of  relations  which  were  consistent  with  theoretical  model 
and  thereby  eliminating  redundancy  in  data  storage. 

One  of  the  problems  encountered  in  using  the  methodology  to  design 
relations  for  internal  model  is  in  deciding  whether  all  attributes 
associated  with  a  particular  key  attribute  be  combined  in  one  relation 
or  separated  into  two  or  more  relations.  For  example,  in  the  relation 
ELPAR,  is  it  useful  to  include  attributes:  Nonlinear  index  and  damage 
flag,  even  when  nonlinear  analysis  or  damage  members  are  not  used  in 


computation.  If  included,  they  introduce  redundancy  in  data  storage, 
but  nelp  in  using  the  same  relation  for  other  types  of  computations. 
Another  problem  is  faced  in  deciding  how  many  relations  to  use  for 
storing  data;  for  example,  connecting  nodes  of  an  element.  If 

connecting  nodes  of  all  types  of  elements  are  stored  in  one  relation, 
then  we  need  to  use  variable  length  vectors  which  requires  more  overhead 
information  to  access  data.  On  the  other  hand,  if  separate  relations 
are  used  for  each  type  of  finite  element,  then  number  of  accesses  to 
different  relations  increases  introducing  inefficiency  in  data  access. 

The  methodology  suggests  schemes  to  satisfy  data  requirements  of 
different  applications  by  using  an  external  data  model.  Even  when  the 
implemented  database  does  not  have  the  data  required  by  certain 
applications  in  the  form  they  need,  the  methodology  suggests  adding  new 
relations  to  provide  the  required  data.  But  by  adding,  new  relations 
containing  data  derived  from  existing  relations  introduces  redundancy  in 
data  storage.  The  methodology  does  not  suggest  solution  to  this 
prohl em . 

In  summary,  the  database  design  methodology  developed  for  finite 
element  analysis  and  structural  design  optimization  is  found  to  be 
extremely  useful.  Intuitive  methods  of  dataoase  design  can  be  replaced 
r>y  a  systematic  approach  for  the  most  part. 
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CHAPTER  8 

IMPLEMENTATION  OF  A  COMPUTER-AIDED  STRUCTURAL 
DESIGN  OPTIMIZATION  SYSTEM  USING  DBMS 

8»1  Introductory  Remarks 

A  computer-aided  structural  design  optimization  system  is 
implemented  using  the  database  designed  in  Chapter  7  and  the  database 
management  system  MIDAS.  This  implementation  is  carried  out  to 
demonstrate  use  of  the  database  and  the  database  management  system  in 
finite  element  analysis  and  structural  design  optimization 
applications.  Also,  the  results  of  the  implementation  will  be  used  in 
evaluaitng  DDL,  DML ,  query  language,  database  design,  performance  of 
DBMS  in  equation  solving  environment,  and  performance  of  design 
optimization  program. 

This  chapter  describes  details  of  the  computer  program  for 
structural  design  optimization.  The  program  is  developed  in  two 
parts.  The  first  part  is  a  general  purpose  finite  element  analysis 
program.  The  second  part  is  a  design  sensitivity  analysis  program.  In 
Section  8.2,  the  capabilities  of  the  program  are  described.  The  program 
design  is  discussed  in  Section  8.3.  Finally,  the  example  problems 
solved  using  the  program  are  given  in  Section  8.4.  Evaluation  of  DBMS 
is  discussed  in  the  next  chapter. 


v*  -O  M 


The  general  purpose  finite  element  analysis  and  design  sensitivity 
programs  have  the  following  capabilities: 

1.  The  program  can  perform  static  analysis,  design  sensitivity 
analysis  and  optimal  design  of  a  structure. 

2.  The  program  can  compute  displacements,  stresses,  cost  and 
constraint  functin  values,  cost  and  constraint  gradients,  impose 
stress,  displacement  and  design  variable  constraints  on  a 
structure. 

3.  The  program  has  an  element  library  consisting  of  two  and  three 
dimensional  truss,  beam,  triangular  membrane,  quadrilateral 
membrane  and  shear  panel  elements.  New  elements  can  be  easily 
added  into  the  library. 

4.  Hypermatrix  scheme  is  used  for  assembly  of  large  matrices  in 
finite  element  analysis  and  design  sensitivity  computations. 

b.  Out-of-core  solution  of  equations  is  carried  out  using 
hypennatrix  scheme. 

6.  The  program  has  modular  structure.  Modules  in  the  program  are 
functionally  independent.  Modification  of  existing  modules  and 
addition  of  new  modules  are  simple  to  carry  out. 

7.  The  program  uses  a  well  designed  database  and  the  database 
management  system  MIDAS. 

8.  Any  large  size  structure  can  be  analyzed  and  designed  using  the 


9.  Program  uses  IDESIGN3  (Arora,  et.  al.,  1984b)  for  finding  the 


design  change  and  optimal  design  computation.  The  program 
IDES IGN3  has  options  to  select  mathemtical  programming  methods, 
like  Hybrid,  RQP  and  cost-function  bounding. 

8.3  System  Design 

In  this  section,  details  of  computer  program  design  for  finite 
element  analysis  and  structural  design  optimization  are  given.  Function 
and  description  of  modules  used  in  the  program  are  given. 

8.3.1  DBMS  Used  in  the  Program 

Data  Management  System  -  MIDAS/R  is  used  in  implementing  the  finite 
element  and  design  sensitivity  programs.  The  subroutines  listed  in 
Section  6.2  are  used  for  database  management  operations.  The  use  of 
MIDAS/R  enables  us  to  evaluate  its  performance  in  design  optimization 
applications.  In  a  parallel  research  study,  the  performance  of  MIDAS/N 
for  finite  element  analysis  and  optimal  design  is  being  evaluated. 

8.3.2  Finite  Element  Analysis  Program 

The  general  purpose  finite  element  analysis  program  developed  has 
several  modules.  They  are  (i)  input  module  (INPUT),  (ii)  data 

generation  module  (STRMGN),  ( i  i  i )  module  for  element  stiffness 
computation  (ELSTF),  (iv)  module  for  assembly  of  stiffness  matrix 
(STIFF),  (v)  module  for  assembly  of  load  matrix  (LOAD),  (vi)  module  for 
solution  of  equations  (SOLEQ),  and  (vii)  module  for  recorvery  of 


displacements  and  stresses  (STRESS).  These  modules  are  functionally 
independent.  They  directly  interact  with  the  database  for  input  and 
output  of  data  using  D8MS.  Various  modules  used  in  the  program  are 
schematically  shown  in  Fig.  8.3.1.  The  function  and  description  of  the 
modules  are  given  in  the  following  paragraphs. 

Input  Module.  The  input  module  reads  the  data  used  in  the  finite 
element  idealization  such  as  material  property,  element  connectivity, 
nodal  coordinates,  boundary  conditions,  and  cross-sectional  property. 
The  data  read  is  stored  in  the  database  for  further  processing.  Data 
for  each  substructure  is  given  seperately.  The  module  has  subroutines 
INTIAL,  DATAIN,  DATELT,  DCORNS,  DATEPR,  DATCON,  ESRELT,  SETDF1 ,  SETDF2, 
and  SE i DF 3 .  Subroutine  INTIAL,  reads  the  general  data  needed  for  a 
structure  such  as  material  properties,  element  types,  and  number  of 
substructures.  DATAIN  reads  general  data  of  a  substructure  such  as 
number  of  elements,  and  number  of  nodes.  Element  connectivity  data  and 
cross-sectional  properties  are  read  in  DATELT.  Coordinate  data  and 
boundary  conditions  are  read  in  subroutine  DCORNS.  Subroutines  DATEPR, 
DATCON  and  ESRELT  store  the  input  data  in  various  relations. 
Subroutines  SETDF1 ,  SETDF2,  and  SETDF3  define  relations  in  a  database. 
These  subroutines  are  again  functionally  independent.  They  call  MIDAS/R 
routines  for  database  management  operations. 
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Figure  8.3.1  Modules  in  Finite  Element  Analysis  Program 
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Nodule  for  Data  Processing.  This  module  generates  data  such  as 
degrees  of  freedom  numbers  for  nodes,  degrees-of- freedom  numbers  for 
elements,  element  number  participating  in  submatrices  of  assembled 
stiffness  matrix,  address  of  submatrices  of  the  hypermatrix  (stiffness) 
and  degrees-of-f reedom  numbers  for  internal  and  boundary  nodes  of  a 
substructure.  The  module  has  subroutines  INBDDF,  PRSCDF,  ELTBOL, 
ELTPGS,  FMNEIP,  LAHMYT,  ENISMP,  SETDF4,  SETDF5  and  SETDF6.  The  module 
uses  the  relations  created  from  the  previous  module  to  generate  data  and 
stores  them  in  new  relations.  Subroutine  INBDDF  and  PRSCDF  generate 
degrees-of-freedom  numbers  at  various  nodes  of  a  substructure. 
Subroutine  ELTBOL  generates  degrees-of-freedom  numbers  of  elements. 
Subroutines  ELTPGS,  LAHMYT  and  ENISMP  are  used  for  generating 
information  about  nonnull  partition  numbers  in  assembled  stiffness 
matrix,  element  numbers  contributing  stiffness  to  submatrices  of  the 
hypermatrix  etc.  Subroutines  SETDF4,  SETDF5  and  SETDF6  are  used  for 
defining  relations  in  the  database. 
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Module  for  Element  Stiffness  Computation.  Element  stiffness  and 
transformation  matrices  are  computed  in  this  module.  The  module  has  a 
library  of  subroutines  to  generate  stiffness  matrices  for  various  finite 
elements  used  in  the  program.  The  library  contains  routines  for  two  and 
three  dimensinal  finite  elements  -  truss,  beam,  triangular  membrane, 
quadri 1 ateral  membrane,  and  shear  panel  elements.  The  subroutines  used 
in  the  module  are  ETRUSS,  EBEAM2 ,  EBEAM3 ,  ETRMEM,  EQDMEM,  SMSPAR,  ESSP, 
TRANS1,  TRANS2  and  TRANS3.  ETRUSS  generates  element  stiffness  matirx 
for  two  and  three  dimensional  truss  elements  in  local  and  global 


coordinate  system.  Element  stiffness  matrix  for  two  and  three 
dimensional  beam  elements  are  generated  in  subroutines  EBEAM2  and 
EBEAM3.  Element  stiffness  matrix  for  triangular  membrane,  quadrilateral 
membrane,  spar  and  shear  panel  elements  are  generated  in  ETRMEM,  EQDMEM, 
SMSPAR,  and  ESSP  respectively.  Transformation  matrices  required  for 
these  elements  are  computed  in  TRANS1,  TRANS2  and  TRANS3.  Options  are 
available  either  to  store  the  element  stiffness  matrix  or  to  generate  it 
as  and  when  required.  New  elements  can  be  added  easily  into  the 
1 ibrary . 

Nodule  for  Assembly  of  Stiffness  Matrix.  This  module  assembles 
stiffness  matrix  of  a  structure.  The  module  has  capability  to  assemble 
any  type  of  finite  element  used  in  a  structure.  The  program  assembles 
the  stiffness  matrix  in  a  hypermatrix  form.  The  submatrices  are 
numbered  as  shown  in  Fig.  8.3.2.  One  submatrix  is  assembled  at  a  time 
using  information  about  element  stiffness  matrices  contributing  to  the 
submatrix.  This  scheme,  therefore,  reducues  the  number  of  I/O  required 
to  assemble  a  matrix.  The  program  has  capability  to  assemble  internal 
and  boundary  stiffness  matrices  required  for  substructure  analysis.  The 
module  has  subroutines  ASMBLY  and  SETDF11.  ASMBLY  subroutine  actually 
assembles  the  stiffness  matrix  for  a  substructure  in  the  hypermatrix 
form.  Options  are  provided  in  the  module  either  to  use  the  element 
stiffness  matrix  data  from  the  database  or  compute  them  when  required. 
Null  submatrices  are  not  assembled. 
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Nodule  for  Assembly  of  Load  Matrix.  Load  matrix  is  assembled  in 
this  module.  Any  number  of  load  cases  can  be  assembled  using  the 
module.  Again  the  assembly  of  load  matrix  is  in  the  hypermatrix  form. 
This  module  reads  the  load  data  and  stores  them  in  relations.  The  load 
data  is  processed  according  to  degrees-of-freedom  and  load  case  numbers, 
and  stored  in  relations.  The  load  assembly  routines  assembles  one  load 
submatrix  at  a  time  using  the  data  created  by  an  earlier  routine.  The 
module  has  capability  to  assemble  internal  and  boundary  load  matrices  of 
a  substructure  seperately.  The  subroutines  in  the  module  are  L0AD1, 
L0AD2,  L0AD4,  L0A05,  SET0F7 ,  and  SET0F8.  Subroutine  L0AD1  reads  the 
loads  acting  at  various  nodes  of  a  substructure  for  different  load 
cases.  Subroutines  L0AD2  and  L0AD4  process  the  load  submatrix  numbers 
and  other  intermediate  data  required  for  load  hypermatrix  assembly. 
Load  matrices  are  assembled  for  each  substructure  in  subroutine  L0AD5. 
SETDF11  routine  defines  relations  needed  for  LOAD  module.  The  load 
submatrix  numbering  is  schematically  shown  in  Fig.  8.3.3.  Null 
submatrices  are  not  assembled. 

Module  for  Solution  of  Equations.  Large  system  of  simultaneous 
equations  are  solved  in  this  module.  The  module  uses  the  stiffness  and 
load  matrices  assembled  in  the  hypermatrix  form.  Out-of-core  solution 
of  equations  is  used.  The  program  decomposes  stiffness  matrix  and 
performs  forward  and  backward  substitutions  on  the  assembled  load 
matrix.  Subroutines  used  in  the  module  are  DRIVE,  FRMVEC,  FRMVEX, 
MODIFY,  GETHYP,  PUTHYP,  TRIPLE  and  MLTPLY.  Subroutines,  DRIVE  and 
MODIFY  decompose  stiffness  matrix. 
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Subroutines  FRMVEC  and  FRMVEX  perform  forward  and  backward  substitutions 
on  the  load  matrix.  PUTHYP  and  GETHYP  store  and  retrieve  submatrices  of 
assembled  matrix.  Subroutines  MLTPLY  and  TRIPLE  are  used  for 
multipl ication  and  triple  multiplication  of  submatrices. 

Nodule  for  Recovery  of  Displacements  and  Stresses.  This  module 
recovers  the  displacement  results  from  the  solution  module  and 
rearranges  them  node-wise  and  load  case-wise.  Again  the  nodal 
displacements  are  rearranged  to  get  displacements  at  the  element 
level.  The  module  also  computes  stresses  in  the  elements  using  the 
element-displacement  information.  The  subroutines  used  in  the  module 
are  DISPI,  DISPE,  ETRMEM  and  ETRUSS.  Nodal  and  element  displacements 
are  recovered  in  subroutines  DISPI  and  DISPE  respectively.  Stresses  for 
triangular  membrane  and  truss  elements  are  computed  in  ETRMEM  and  ETRUSS 
respectively. 

8.3.3  Design  Sensitivity  Analysis  Program 

Design  sensitivity  analysis  program  has  several  modules.  They  are 
(i)  cost  function  module  (COST),  (ii)  constraint  function  module 
(CONFUN),  (iii)  cost  gradient  module  (CSTGRD),  (iv)  partial  derivatives 
of  element  and  node  related  constraints  (PARDV),  (v)  assembly  of  dh/db 
matrix  (DHDB),  (vi)  solution  for  dz/db  (DZDB),  and  (vii)  constraint 
gradient  module  (CONGRD).  These  modules  are  functionally  independent. 
They  directly  intereact  with  the  database  for  accessing  data  required 
for  computation.  The  various  modules  used  in  the  program  are  shown  in 
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My.  8.3.4.  The  function  and  description  of  these  modules  are  given  in 
the  following  paragraphs. 

Cost  Function  Nodule.  This  module  computes  the  cost  of  a 
structure.  The  module  computes  the  volume  of  each  element  used  in  the 
structure  and  multiplies  by  its  material  density  to  obtain  the  mass  of 
the  structure.  Subroutine  CSTTRS  is  used  for  computing  mass  of  each 
truss  elements.  Module  has  provision  to  add  cost  function  for  other 
types  of  elements. 

Constraint  Funtion  Module.  This  module  computes  constraint 
function  of  element  related  and  node  related  constraints.  The  module 
generates  constraint  numbers  correspondi ng  to  element  and  node  related 
constraints.  Also,  global  constraint  numbers  are  generated.  Element 
related  constraints  are  stress  limits  on  elements.  Node  related 
constraint  functions  are  displacement  limit  at  various  degrees  of 
freedom.  The  module  has  subroutines  CONFUN,  ELMSTR,  and  ETRUSS. 
Subroutine  CONFUN  generates  constraint  numbers  and  stores  them  in  the 
database.  Subroutine  ETRUSS  computes  stress  constraint  for  each  truss 
element.  Stress  constraints  for  other  types  of  elements  can  be  added 
into  this  module. 

Cost  Gradient  Module.  Cost  gradient  of  a  structure  is  computed  in 
tnis  module.  The  cost  gradient  computation  are  carried  out  with  respect 


to  each  design  variable  and  stored  in  a  vector.  Cost  gradients  for 
truss  elements  are  computed  in  subroutine  CSTTRS. 


Partial  Derivatives  of  Element  and  Node  Related  Constraints.  The 


partial  derivatives  of  element  and  node  related  constraints  wih  respect 
to  displacements  are  computed  in  this  module.  The  module  has 

subroutines  ELMSTR  and  ETRUSS  to  compute  deriatives  of  constraints  for 
truss  element.  The  derivatives  are  stored  in  the  database. 

Module  DHDB.  The  module  assembles  dh/db  matrix  for  a  structure. 
The  module  computes  unit  stiffness  matrix  of  various  elements  in  the 

structure  and  multiplies  with  corresponding  displacements  and  assembles 
the  matrix.  The  matrix  is  assembled  in  the  hypermatrix  form.  The 

module  has  subroutines  ASMDHB,  STFGEN,  and  ETRUSS.  Subrouinte  ASMDHB 
assembles  the  dh/db  in  hypermatrix  form.  Assembly  procedure  is  similar 
to  that  for  the  stiffness  matrix.  Here  the  rows  of  the  assembled  matrix 
correspond  to  degrees  of  freedom  numbers  and  the  columns  correspond  to 
design  variable  numbers.  Subroutine  STFGEN  calls  ETRUSS  or  other 
routines  depending  on  the  lement  type.  Subroutine  ETRUSS  computes  unit 

stiffness  matrix  for  truss  elements  and  multiplies  with  the 

d  k 

correspondi ng  element  displacements  and  returns  the  matrix  •  z. 

Module  DZDB.  This  module  obtains  solution  for  dz/db  using 
decomposed  stiffness  matrix  and  dh/db  matrix.  The  solution  procedure  is 
the  same  as  described  for  solution  of  displacements.  Out-of-core 
solution  of  equations  is  carried  out  usiny  the  assembled 
hypermatrices.  The  module  has  subroutines  FRMVEC,  FRMVEX,  MLTPLY, 
TRiPLE,  PUTHYP  and  GETHYP.  Subroutine  FRMVEC  and  FRMVEX  perform  forward 
and  backward  subst i t i t ions  on  right  hand  side  matrix.  Subroutine  MLTPLY 


and  TRIPLE  perform  multiplication  and  triple  multiplcation  of 


submatrices.  PUTHYP  and  GETHYP  stores  and  retrieves  submatrices  in  the 


database. 


Constraint  Gradient  Module.  Constraint  gradients  of  a  structure 


are  computed  in  this  module. 


The  module  multiplies  the 


vectors  34'/ 3 z  and  dz/db  to  obtain  constraint  gradients  d4>/db  of  a 


structure.  The  constraint  gradients  are  stored  in  the  database  for  use 


in  IDESIGN3  program.  These  computations  are  done  in  subroutine  SENSTV. 


IDESIGN3  Program.  IDESIGN3  program  (Arora  and  et .  al  . ,  1984b)  is 


used  to  solve  the  minimization  problem.  The  cost  and  constraint 


functions  and  their  gradients  are  supplied  to  the  program  through  the 


database.  The  design  change  values  returned  by  the  program  are  stored 


in  the  database.  With  the  new  values  of  the  design  variables,  the 


finite  element  analysis  and  design  sensitivity  computations  are 


repeated.  CPL  commands  of  PRIME  computer  system  are  used  to  run  the 


program  iteratively. 


8.4  Example  Problems  Solved  Using  the  Program 


Several  example  problems  are  solved  usign  the  structural  design 


optimization  program.  These  examples  enable  us  to  evaluate  several 


aspects  of  the  computer-aided  structural  design  optimization  process. 


First  of  all,  the  examples  show  that  many  practical  structural 


optimization  problems  can  be  solved  using  the  program.  Secondly,  the 


performance  of  the  program  can  be  evaluated.  Thirdly,  it  is  possible  to 
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evaluate  the  use  of  database  and  database  management  system  in  the 
program. 

Problems  solved  using  the  program  are  (i)  10-bar  truss  (ii)  25-bar 
truss  (iii)  47-bar  truss  (iv)  72-bar  truss  (v)  200-bar  truss  (vi)  108- 
bar  helicopter  tail  boom.  The  problems  solved  are  shown  in  Figs.  8.4.1 
to  8.4.6.  Data  for  these  problems  were  obtained  from  Thanedar,  Park  and 
Arora  (1985).  The  optimum  cost  results  obtained  using  the  program  was 
found  to  agree  with  those  given  in  the  reference.  The  intention  of 
solving  these  problems  was  to  evaluate  the  use  of  database,  database 
management  system  and  the  computer  program  efficiency.  Results  of 
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CHAPTER  9 


EVALUATION  OF  DATABASE,  MIDAS  AND  COMPUTER 
PROGRAM  FOR  STRUCTURAL  DESIGN  OPTIMIZATION 


9.1  Introductory  Remark 

In  this  chapter,  the  database,  the  database  management  system  - 
MIDAS,  and  the  computer  program  for  structural  design  optimization  are 
evaluated.  This  evaluation  is  intended  to  bring  out  suitability  and 
drawbacks  associated  with  the  use  of  the  database  and  the  database 
management  system  in  the  computer-aided  structural  design  optimization 
environment.  Note  that  the  suitability  and  drawbacks  of  various 
database  management  concepts  have  been  already  discussed  in  Chapter 
3.  Also,  the  methodology  developed  to  design  a  database  was  evaluated 
in  Section  7.6.  Evaluation  of  the  database  used  in  the  structural 
design  optimization  program  is  given  in  Section  9.2.  The  database 
management  system  -  MIDAS  is  evaluated  in  Section  9.3.  The  MIDAS/R  data 
definition,  data  manipulation  and  query  language  of  MIDAS  are 
evaluated.  Performance  of  MIDAS  in  engineering  applications  is  given. 
Finally  the  performance  of  the  computer  program  for  structural  design 
optimization  is  discussed. 

9.2  Evaluation  of  the  Database 
Used  in  the  Program 

The  design  of  the  database  and  the  computer  program  were 
discussed  in  Chapters  7  and  8,  respectively.  Several  criteria  are 
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selected  to  evaluate  the  database.  They  are  (i)  Simplicity,  (ii)  Ease 
of  use,  (iii)  Ability  to  represent  structural  design  data,  (iv)  Data 
redundancy,  (v)  Data  consistency,  (vi)  Efficiency  of  data  access,  (vii) 
Ability  to  satisfy  data  needs  of  future  applications,  (viii)  Ability  to 
store  additional  data,  (ix)  Accommodation  of  various  data  types,  (x) 
Representation  of  large  vectors  and  matrices,  (xi)  Iterative  data 
organization,  (xii)  Data  independence,  (xiii)  Ease  of  database  design, 
and  (xiv)  Impl ementational  requi rements . 

Simplicity.  The  computer  program  used  the  simple  tabular  structure 
of  the  database  which  was  designed  using  a  relational  model.  The 
general  tabular  from  of  data  such  as  element  connectivity,  nodal 
coordinates,  and  material  property,  was  found  simple  to  organize  using 
the  relational  data  model.  The  program  was  able  to  organize  large 
matrices  and  vectors  in  a  simple  way  using  the  numerical  data  model. 
The  simplicity  of  data  organization  was  realized  from  the  point  of  view 
of  users  of  the  database. 

Ease  of  Use.  The  database  was  found  easy  to  use  in  the  structural 
design  optimization  application  program.  Rows  of  relations  were  stored 
and  retrieved  easily.  Large  vectors  and  matrices  were  stored  and 
retrieved  easily  in  row  or  submatrix  order. 

Ability  to  Represent  Structural  Design  Data.  The  computer  program 
used  the  database  to  store  all  the  data  used  and  generated  in  the  finite 
element  analysis,  design  sensitivity  and  design  change  computations. 
The  database  was  able  to  represent  both  the  tabular  and  matrix  type  of 
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data  used  in  the  computation.  Tabular  type  of  data  was  appropriately 
represented  in  the  database  using  the  relational  data  model.  Large 
matrices  and  vectors  were  suitably  represented  in  the  database  using  the 
numerical  data  model.  However,  it  was  found  that  the  database  design 
was  not  adequate  to  accommodate  some  particular  data,  such  as 
intermediate  data  needed  for  assembly  of  large  stiffness  and  load 
matrices.  This  was  because,  these  types  of  data  were  not  included  while 
designing  the  conceptual  and  internal  model  of  the  database.  Examples 
of  intermediate  data  are  -  element  numbers  contributing  to  submatrices 
of  assembled  stiffness  matrix,  and  load  case  numbers  corresponding  to 
load  submatrices.  In  such  cases,  additional  relations  were  added  at  the 
implementation  stage  to  store  the  intermediate  data.  Data  belonging  to 
a  structure,  substructures,  elements  and  nodes  was  represented  using  the 
relational  data  model.  Even  though,  the  relational  data  model  was  able 
to  accommodate  these  data,  the  model  did  not  take  advantage  of  the 
hierarchical  pattern  of  data.  The  relational  data  model  accommodated, 
for  example,  data  belonging  to  substructures  by  assigning  substructure 
numbers  to  the  relation  names.  Representation  of  data  belonging  to 
different  loading  cases  was  possible  by  including  an  additional 
attribute  in  relations  corresponding  to  loading  case  numbers.  However, 
this  was  found  inconvenient  to  use,  since  it  neccessiated  use  of 
pointers  to  rows  to  identify  data  of  a  particular  load  case.  In 
general  ,  most  of  the  data  used  by  the  computer  program  was  represented 


in  the  database. 
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Data  Redundancy.  It  was  found  that  the  data  redundancy  in  the 
database  was  minimum  because  of  the  rigorous  methodology  used  while 
designing  the  database.  In  some  instance,  data  redundancy  occurred 
because  of  the  addition  of  new  relations  during  the  implementation  stage 
of  the  computer  program.  New  relations  had  to  be  included  in  the 
database  either  because  of  faulty  database  design  or  to  minimize  number 
of  access  required  to  retrieve  the  data.  For  example,  it  was  necessary 
to  include  a  relation  EPRO  containing  data  derived  from  relations  ELVEC 
and  NODVEC  to  minimize  number  of  accesses  to  the  database.  In  another 
instance,  when  only  one  load  case  is  used  in  the  computations,  then  load 
case  attribute  in  relations  ELRES,  SUBVEC  and  STRVEC  become  redundant. 
Therefore,  it  was  realized  that  it  was  impossible  to  avoid  total  data 
redundancy  in  the  database.  But,  the  database  as  such  satisfied  the 
requirement  of  minimum  data  redundancy. 

Data  Consistency.  To  a  large  extent,  the  data  in  the  database  was 
stored  consistently.  Some  inconsistency  in  data  may  still  occur  because 
of  the  redundant  data  in  the  database.  As  explained  earlier,  redundancy 
in  the  database  was  present  due  to  addition  of  new  relations  such  as 
EPRD.  To  see  if  the  database  is  consistent,  consider  modification  of 
the  relation  EPRD  due  a  change  in  cross-sectional  property,  data.  If 
cross-section  data  is  changed  in  this  relation  and  if  corresponding 
changes  are  not  made  in  the  relation  ELVEC  containing  the  same  data, 
then  the  data  in  the  database  becomes  inconsistent.  To  overcome  this 
problem,  the  application  program  was  designed  to  keep  track  of  the 
redundant  data  and  make  proper  changes  in  the  required  relations. 


Efficiency  of  Data  Access.  The  computer  program  for  structural 

design  optimization  was  able  to  access  the  data  required  for  computation 
to  minimize  the  in  a  minimum  number  of  accesses.  It  was  possible  to 
minimize  the  number  of  accesses  to  database  by  designing  various 
relations  using  the  methodology  discussed  in  Chapter  IV.  For  example, 
one  access  to  database  was  sufficient  to  retrieve  data  of  element 
displacements.  With  two  access  to  the  database,  material  property  of  a 
particular  element  was  obtained.  In  this  case,  first  access  retrieved 
the  material  number  used  by  an  element,  and  the  second  access  retrieved 
the  actual  material  property  values.  Again,  two  accesses  were  required 
to  get  data  for  assembly  of  stiffness  matrix.  Here,  one  access  was 

required  to  obtain  element  degree  of  freedom  numbers  and  another  access 
to  get  element  stiffness  matrix.  Assembly  process  was  made  more 

efficient  by  not  storing  element  stiffness  matrices  in  the  database, 
thereby  reducing  the  number  of  accesses  to  the  database  to  only  one. 
Element  stiffness  matrices  were  generated  as  and  when  they  were 
needed.  This  computation  of  element  stiffness  matrices  needed  data  from 
three  different  relations.  For  example,  to  get  coordinates  of  nodes  and 
material  property  of  a  particular  element,  access  was  needed  to  the 
relation  containing  node  numbers  and  material  number  of  the  element;  to 
the  relation  containing  coordinates  of  nodes;  and  material  property 
values.  For  an  n  node  element,  n  accesses  to  relation  containing 

coordinates  of  data  were  necessary.  To  increase  the  efficiency  of 
accessing  data  for  stiffness  computation,  element  nodal  coordinates  and 
cross-sectional  properties  were  stored  together  at  the  expense  of  data 


redundancy.  In  case  of  large  matrices,  the  database  design,  however, 
lacks  efficiency  in  accessing  a  matrix  data  in  column  order  which  was 
stored  in  a  row  order  or  vice  versa.  This  kind  of  operation  requires  a 
very  large  number  of  accesses  to  the  database.  In  general,  the  database 
was  able  to  provide  data  in  an  efficient  way. 

Ability  to  Satisfy  Data  Needs  of  Future  Applications.  The 

relations  used  in  the  database  are  capable  of  expanding  both 
horizontally  and  vertically  to  satisfy  the  needs  of  future 
applications.  Addition  of  new  attributes  at  the  end  of  existing 
attributes  in  a  relation  brings  about  horizontal  growth  of  a  relation. 
Addition  of  new  relations  will  provide  vertical  growth  of  the 
database.  For  example,  consider  the  need  to  use  the  database  for 
nonlinear  analysis.  Assuming  that  the  existing  relation  ELPAR  does  not 
have  an  attribute,  for  example  nonlinearity  index,  then  this  attribute 
is  added  into  the  relation.  By  this  method,  both  the  existing  and  the 
new  application  program  will  be  able  to  use  the  same  database.  This 
addition  of  new  attributes  does  not  require  any  modification  of  existing 
application  using  the  relation.  This  addition  of  a  new  attribute  which 
is  associated  with  a  particular  entity  (in  this  case-element)  is 
possible  only  when  the  implemented  relation  has  this  entity  key; 
otherwise,  a  new  relation  is  added  to  the  set  of  existing  relations  to 
make  the  database  grow  vertically.  Thus,  we  see  from  the  above 
discussion,  that  the  database  has  capability  to  satisfy  the  data  needs 


Ability  to  Store  Additional  Data.  The  relations  used  in  the 
database  have  almost  no  limitation  in  storing  any  number  of  rows  of 
data.  Also,  the  relations  have  the  capacity  to  store  data  as  and  when 
they  are  created  during  various  stages  of  computation.  This  capability 
was  achieved  since  the  database  uses  hash  addressing  scheme  to  specify 
storage  location  of  rows  of  various  relations.  But,  it  was  found  that 
this  scheme  has  disadvantage  in  not  locating  particular  rows  of  a 
relation  in  minimum  number  of  accesses.  Later,  in  Section  9.4,  it  will 
be  shown  that  the  number  of  accesses  to  the  physical  database  is  very 
high  using  this  scheme.  Further,  for  a  particular  implementation  of 
relations  in  the  database,  number  of  attributes  in  a  relation  is 
fixed.  Therefore,  it  is  not  possible  to  add  additional  attributes  after 
a  relation  has  already  been  defined  using  DDL.  But,  by  modifying  6.<ta 
definition  call  statements,  new  attributes  can  be  added  easily. 


Ability  to  Store  Different  Data  Types.  In  the  computer  program  for 
structural  design  optimization,  several  different  data  types  -  integer, 
real,  double  precision  and  character  words  were  used.  Data  belonging  to 
these  data  types  were  stored  in  relations.  Attributes  of  the  relations 
in  the  database  used  these  data  types  in  many  different  combinations. 
Therefore,  the  database  has  the  ability  to  store  different  data  types. 


Ability  to  Store  Large  Vectors  and  Matrices.  The  database  was  able 
to  store  large  matrices  and  vectors  needed  for  computation.  Systematic 
organization  of  large  matrices  and  vectors  was  possible  by  using  the 
numerical  data  model.  Vectors  were  stored  in  row  order.  Matrices  were 
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stored  submatrix  order.  The  database  was  able  to  accommodate  variable 
length  vectors.  Database,  however,  does  not  have  the  capability  to 
store  vectors  in  column  order.  The  size  of  a  row  is  limited  to  1024 
words.  Number  of  elements  in  a  submatrix  cannot  exceed  1024  words.  The 
database  design,  also  lacks  the  capability  to  avoid  storage  of  zero 
values  within  a  row,  or  submatrix. 

Ability  to  Organize  Iterative  Data.  The  database  has  the 
flexibility  to  accommodate  iterative  data  of  structural  design 
optimization.  At  the  implementation  stage  of  the  database,  the 
relations  and  matrices  were  classified  into  two  groups,  one  group 
containing  data  which  remained  unaltered  at  various  iterations,  and  the 
second  group  whose  data  changed  in  each  iteration.  Where  data  of 
previous  iteration  was  not  needed  they  were  deleted  at  the  beginning  of 
the  current  iteration.  The  concept  of  global  and  local  databases  was 
used  to  support  the  iterative  data. 

Data  Independence.  The  physical  storage  structure  of  the  database 
is  transparent  to  the  user.  The  user  or  application  program  operates 
only  on  the  logical  database.  The  physical  storage  structure  can  alter 
without  affecting  the  application  program.  Hence,  data  independence  is 
achieved  in  the  database  design. 

Ease  of  Database  Design.  Even  though,  the  conceptual  data  model 
was  found  tedious  to  design,  it  was  found  very  useful  to  design 
relations  in  the  database.  Relations  for  the  internal  data  model  were 
easy  to  construct  simply  by  specifying  various  attributes  in  a 


relation.  Also,  modification  of  one  relation  generally  did  not  force 
reorganization  of  other  relations  that  were  already  designed.  It  was 
found  easy,  to  add  new  relations  into  the  database,  since  no  pointers  or 
links  were  needed  to  other  relations.  Also,  large  matrix  data 
organization  using  numerical  data  model  was  found  easy  to  incorporate  in 
the  database. 

Implementational  Requirement.  The  database  design  did  not  impose 
any  special  restrictions  on  the  use  of  a  particular  database  management 
system.  Even  though,  the  database  for  the  structural  design 
optimization  program  was  implemented  using  MIDAS/R,  it  is  also  possible 
to  use  MIDAS/N. 


9.3  Evaluation  of  DDL,  DHL  and  Query 
Language  of  MIDAS*  ~ 

The  data  definition,  data  manipulation  and  query  languages  of 
MIDAS/R  were  used  in  the  computer  program  for  structural  design 
optimization.  The  subroutines  needed  for  using  these  languages  were 
described  in  Section  6.2.  These  subroutines/commands  are  evaluated  here 
to  see  if  they  satisfied  the  requirements  specified  in  Sections  5.3  to 
5.5.  This  evaluation  brings  out  the  suitability  and  drawbacks  in  using 
these  languages  in  computer-aided  structural  design  application,  the 
evaluation  is  based  on  the  experience  in  using  these  languages  in  the 
computer  program  described  in  Chapter  8. 


Evaluation  of  DDL  of  MIDAS/R.  The  computer  program  used  the  data 
definition  language  of  MIDAS/R  to  define  various  relations  and  matrices 


needed  for  computation.  Subroutines  of  DDL  were  found  simple  to  use. 


MIDAS/R  could  define  and  use  only  one  database  at  a  time.  The  database 


and  relation  names  had  to  be  less  than  6  and  8  characters. 


respectively.  It  did  not  impose  any  restrictions  in  defining  any  number 


of  relations  in  a  database.  There  was  some  restriction  in  the 


definition  of  the  length  of  a  row  of  a  relation  which  was  limited  to 


1024  words.  Because  of  this,  large  vectors  and  matrices  could  not  be 


accommodated  in  a  relation.  This  problem  was  overcome  to  a  certain 


extent  by  the  use  of  submatrix  approach  to  store  data  of  large 


matrices.  The  language  satisfied  the  requirements  of  dealing  with 


various  data  types  integer,  real,  double  precision  and  character 


words.  Since  the  number  of  rows  in  a  relation  is  not  required  to  be 


specified  during  data  definition,  MIDAS/R  provided  flexibility  in 


allowing  any  number  of  rows  in  a  relation.  The  DDL  did  not  provide  any 


facility  to  define  relations  and  matrices  for  several  substructures  in 


the  same  database.  Because  of  this,  same  relation  and  matrix  names 


could  not  be  used  for  data  definition  of  substructures  in  one 


database.  This  problem  was  overcome  by  concatenating  substructure 


number  with  the  relation  or  matrix  name.  Redefinition  of  attributes  in 


a  relation,  neccessiated  definition  of  a  new  relation  and  copying 


portion  of  data  from  the  existing  relation  to  the  new  relation.  The  DDL 


did  not  provide  any  facility  to  allow  the  user  to  specify  number  of 


pages  and  page  size  for  efficient  utilization  of  available  memory, 


Since  the  application  programmers  generally  have  the  knowledge  about 


particular  relations  and  matrices  needed  at  various  stage  of 
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computation,  control  in  deciding  the  page  replacement  should  be  made 
available  to  the  application  programmers.  Other  than  some  of  the 
restrictions  discussed  above,  the  DDL  satisfied  the  requirements 
specified  in  Section  5.3. 


Evaluation  of  DHL  of  MIDAS/R.  The  computer  program  for  structural 
design  optimization  used  the  data  manipulation  language  of  MIDAS/R.  The 
DML  provided  a  set  of  subroutines  which  were  useful  and  convenient  in 
storing,  retrieving,  modifying  and  deleting  data  in  the  database.  The 
language  satisfied  the  requirements  specified  in  Section  5.4.  Several 
points  are  noted  after  using  the  DML  in  the  computer  program.  MIDAS/R 
could  only  operate  on  one  database  at  a  time.  If  several  databases  are 
needed  then  they  have  to  be  used  one  after  another  by  opening  and 
closing  the  databases.  RDSGET  and  RDSPUT  routines  operate  on  one  row  at 
a  time.  Even  though,  these  routines  have  a  less  number  of  arguments, 
some  penalty  has  to  be  paid  in  terms  of  efficiency  when  several 
successive  rows  have  to  be  stored  or  retrieved.  From  this  point  of 
view,  it  is  better  to  have  starting  and  ending  row  numbers  in  the 
arguments  of  these  subroutines  to  minimize  number  of  calls  to  the 
database.  The  DML  of  MIDAS/R  requires  a  call  to  RDSGET  before  actually 
modifying  the  data  using  RDSMOD.  This  was  found  inconvenient  to  use. 


Evaluation  of  Query  Language.  The  query  language  of  MIDAS/R  served 
two  purposes.  First,  it  was  found  very  useful  in  developing  and 
debugging  the  computer  program  for  structural  design  optimization. 
Secondly,  the  query  language  provided  a  simple  set  of  commands  to 
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interactively  define  and  manipulate  the  database.  While  developing  and 
debugging  the  application  program,  query  commands  of  MIDAS/R  such  as 
SELECT,  LIST,  CHANGE  and  DELETE  were  used  to  see  if  the  application 
program  has  correctly  defined  and  manipulated  a  database  using  the 
subroutines  for  DDL  and  DML.  Sometimes,  the  incorrect  data  stored  in  a 
database  due  to  erroneous  application  program  logic  was  rectified  using 
the  query  commands.  Display  of  assembled  stiffness  submatrices  on  the 
terminal  was  sometimes  useful  in  checking  the  correctness  of  the 
assembly  procedure.  Query  language  of  MIDAS/R  was  found  very  useful  for 
pre-  and  post-processing  of  data.  Commands  like  'SELECT  STRESS  GT 
100.0',  'SELECT  DISPLACE  GT  10.0  AND  LT  100.0',  'SELECT  C00RD-X  FROM 
NODE  DATA'  was  found  very  useful.  Query  language  provided  a  simple  set 
of  commands  to  see  the  contents  of  the  database.  The  language  satisfied 
the  requirements  specified  in  Section  5.5. 

9.4  Evaluation  of  MIDAS  in  Structural 
Design  Applications 

In  this  section,  evaluation  of  MIDAS  in  structural  design 
applications  is  made.  Out-of-core  linear  simultaneous  equation  solvers 
are  developed  to  evaluate  the  performance  of  MIDAS.  Two  types  of 
equation  solvers  are  developed,  one  using  skyline  approach  and  another 
using  hypermatrix  approach.  First,  the  performance  of  MIDAS/N  and 
MIDAS/R  are  evaluated  using  skyline  approach.  Later,  they  are  evaluated 
usinn  hypermatrix  approach.  This  evaluation  brings  out  several  aspects 
such  as  efficiency  of  MIDAS/N  and  MIDAS/R  in  equation  solving 
environment,  suitability  of  skyline  and  hypermatrix  approach  for  large 


equation  solving  applications,  use  of  memory  management  in  engineering 
application,  and  design  aspect  of  structural  optimization  program.  In 
the  following  subsections  and  details  of  evaluation  are  given. 


9.4.1  Skyline  and  Hyperaatrix  Approaches 

Computer  programs  for  solving  equations  using  skyline  and 
hypermatrix  approaches  are  developed.  The  skyline  approach  uses  left 
hand  side  coefficient  matrix  in  the  skyline  form.  Each  column  of  the 
LHS  coefficient  matrix  is  of  variable  length  storing  only  nonzero 
values.  Each  column,  however,  includes  zero  values  within  it.  The 
right  hand  side  and  solution  for  unknowns  are  stored  in  a  column 
vector.  Numerical  data  model  consisting  of  two  levels  of  matrix  data 
organization  is  used.  First  level  contains  details  about  skyline  height 
and  addresses  of  diagonal  elements  and  the  second  level  contains  actual 
matrix  data.  Two  separate  programs  are  developed  for  solving  equations, 
one  using  MIDAS/N  and  the  other  using  MIDAS/R  system. 

Computer  program  for  solving  equations  using  hypermatrix  approach 
use  LHS  coefficient  matrix  in  the  hypermatrix  form.  Large  matrix  is 
divided  into  number  of  submatrices.  Only  upper  symmetric  portion  of  LHS 
matrix  is  stored.  Similarly  the  RHS  matrix  is  also  divided  into  a 
number  of  submatrices.  The  solution  vectors  are  also  stored  in 
submatrix  form.  Null  submatrices  in  LHS  and  RHS  hypermatrices  are  not 
stored  and  manipulated.  Partially  full  submatrix,  however,  stores  zero 
coefficients  within  it.  Again,  numerical  data  model  is  used  for  matrix 
data  organization.  First  level,  contains  nonnull  submatrix  numbers  and 
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their  sizes,  and  second  level  contains  actual  matrix  data.  Another  two 
programs  are  developed;  one  using  MIDAS/N  and  other  using  MIDAS/R 
system. 

Both  the  approaches  use  Gaussian  elimination  scheme  to  decompose 
the  coefficient  matrix.  Forward  and  backward  substitutions  are  carried 
out  to  obtain  solution  of  equations. 

Thus,  totally  four  computer  programs  are  developed  for  solving 
equations.  Program  SKYSOL  solves  equations  using  MIDAS/R  by  the  skyline 
approach.  Program  SKYSOLB  (Shyy,  1985)  solves  equations  using  MIDAS/N 
by  the  skyline  approach.  Program  HYPSOL  uses  MIDAS/R  to  solve  equations 

by  hypermatrix  approach.  Program  HYPMDN  uses  MIDAS/N  to  solve  equations 

by  the  hypermatrix  approach. 

Two  sets  of  large  equations  are  solved  using  the  four  computer 

programs  SKYSOL,  SKYSOLB,  HYPSOL  and  HYPMDN.  First  set  of  equations  has 
1000  unknowns  and  half  band  width  of  10.  Second  set  of  equations  has 
1000  unknowns  and  half  band  width  of  30.  For  hypermatrix  approach 

submatrix  size  of  10  is  used.  These  equations  are  solved  with  different 

memory  management  schemes.  Performances  of  these  programs  are  measured 
by  noting  central  processing  unit  time  (CPU),  number  of  reads  made  on 

physical  database  (NREAD),  number  of  writes  made  on  physical  database 

(NWRITE),  and  number  of  calls  made  to  database  management  subroutines 
( NCALL) . 

The  details  of  performance  of  these  programs  are  given  in 

subsequent  sections. 
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9.4.2  Performance  of  MIDAS/R 

The  two  computer  programs  SKYSOL  and  HYPSOL  using  MIDAS/R  were  used 
to  solve  the  two  sets  of  equations.  The  results  of  CPU,  NREAD,  NWRITE 
and  NCALL  are  given  in  Table  9.4.1.  The  table  shows  the  results  for 
different  cases  of  page  size  and  number  of  pages.  Three  different  cases 
(i)  20  pages  of  256  short  integer  words,  (ii)  20  pages  of  1024  short 
integer  words,  and  (iii)  2  pages  of  20480  short  integer  words  are  used. 

The  following  points  are  observed  from  the  table.  As  the  page  size 
is  increased  CPU  time  for  solving  equations  using  skyline  and 
hypermatrix  approaches  reduces.  Number  of  reads  (NREAD)  for  large  page 
size  is  less  than  for  small  page  size.  NWRITE  also  had  similar  trend 
except  for  the  case  of  hypermatrix  approach  with  page  size  of  1024 
words,  where  NWRITE  increased  when  page  size  is  increased.  The  number, 
of  writes  is  much  smaller  than  number  of  reads.  This  may  be  due  to  the 
hash  index  scheme  used  in  the  MIDAS/R  addressing  and  searching 
routines.  The  MIDAS/R  program  makes  a  huge  number  of  reads  to  search 
and  locate  the  required  data.  Further,  note  that  number  of  calls  to 
MIDAS/R  routines  remained  same  for  all  page  sizes,  as  expected.  Number 
of  calls  to  MIDAS/R  increased  as  bandwidth  increased. 

Skyline  approach  for  solving  first  set  of  equations  with  a  page 
size  of  256  words  took  228.55  seconds,  whereas  hypermatrix  approach  for 
solving  same  equations  with  same  memory  management  scheme  took  2720.87 
seconds.  The  hypermatrix  approach  is  about  10  times  slower  than  the 
skyline  approach.  In  solving  the  second  set  of  equations  with  band 
width  of  30,  skyline  approach  used  3138.66  CPU  seconds,  whereas 


Table  9.4.1  Performance  of  M1DAS/R 


Number  of  equations  :  1000 

Half  band  width  :  10 


Page  Number  of  Skyline  Approach  Hypermatrix  Approach 

Size  Pages  _ 


CPU 

NREA0 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

256 

20 

228.55 

16103 

218 

12984 

2720.87 

92312 

564 

12082 

1024 

20 

119.00 

13970 

74 

12984 

1623.00 

50678 

619 

12082 

20480 

2 

50.75 

303 

65 

12984 

928.00 

26644 

495 

12082 
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Page  Number  of  Skyline  Approach  Hypermatrix  Approach 

Size  Pages  _ 


CPU 

NREAD 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

256 

20 

3138.66 

65602 

530 

32594 

8207.61 

275060 

1157 

24117 

1024 

20 

1576.16 

31417 

191 

32594 

3717.68 

115788 

1327 

24117 

20480 

2 

1297.96 

27481 

145 

32594 

1311.56 

27497 

2598 

24117 

hypermatrix  approach  used  8207.61  CPU  seconds.  In  this  case,  the 
hypermatrix  approach  is  about  3  times  slower  than  the  skyline 
approach.  Thus,  we  see  from  the  results  that  as  band  width  is  increased 
the  difference  in  CPU  time  between  skyline  and  hypermatrix  approaches 
reduces . 

9.4.3  Performance  of  MIDAS/N 

The  two  computer  programs  SKYSOLB  (Shyy,  1985)  and  HYPMDN  using 
MIDAS/N  were  used  to  solve  the  two  sets  of  equations.  The  results  of 
CPU,  NREAD,  NWRITE  and  NCALL  are  given  in  Table  9.4.2.  The  equations 
are  solved  for  different  cases  of  page  size  and  number  of  pages.  Two 
different  cases  (i)  20  pages  of  256  short  integer  words,  and  (ii)  20 
pages  of  1024  short  integer  words. 

The  following  points  are  observed  from  the  table.  As  the  page  size 
is  increased  from  256  words  to  1024  words,  the  CPU  time  for  solving 
equation  using  skyline  and  hypermatrix  approaches  reduces,  but  not  to  a 
considerable  extent.  Number  of  reads  and  number  of  writes  for  large 
page  size  is  much  less  than  for  small  page  size.  Number  of  writes  is 
smaller  than  number  of  reads.  This  is  due  to  replacement  of  unmodified 
pages  by  new  data  causing  more  reads  than  writes.  Note  that  number  of 
calls  to  MIDAS/N  routines  remains  same  for  all  page  sizes  as  expected. 
Numbe^  of  calls  to  MIDAS/N  increased  as  band  width  increased. 

Skyline  approach  for  solving  equations  of  1000  unknowns  with  a  half 
band  width  of  10  and  page  size  of  256  words  took  33.05  seconds,  whereas 
hypermatrix  approach  for  solving  same  equation  with  same  memory 


Table  9.4.2  Performance  of  MIDAS/ N 


Number  of  equations  :  1000 

Half  band  width  :  10 


Page  Number  of  Skyline  Approach  Hypermatrix  Approach 

Size  Pages  _ 


CPU 

NREAD 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

256 

20 

33.05 

340 

127 

16262 

248.10 

22698 

1001 

11487 

1024 

20 

30.69 

70 

30 

16262 

211.40 

6013 

339 

11487 

Number  of  equations  :  1000 

Half  band  width  :  30 


Page  Number  of  Skyline  Approach  Hypermatrix  Approach 

Size  Pages  _ _ _ 


CPU  NREAD  NWRITE  NCALL  CPU  NREAD  NWRITE  NCALL 


management  scheme  took  248.10  seconds.  The  hypermatnx  approach  is 
about  8  times  slower  than  the  skyline  approach.  In  solving  the  second 
set  of  equations  with  a  band  width  of  30,  skyline  approach  used  125.36 
seconds,  whereas  hypermatrix  approach  used  486.02.  In  this  case, 
hypermatrix  is  about  4  times  slower  than  the  skyline  approach.  We  see 
from  the  result  that  as  band  width  increases  the  difference  in  CPU  time 
between  skyline  and  hypermatrix  approaches  reduces.  The  reason  being, 
percentage  of  nonzero  elements  within  the  nonnull  submatrices 
considerably  reduces  as  band  width  increases  in  the  two  sets  of 

equations.  Arithmetic  operations  on  nonzero  elements  reduces  with  less 
percentage  of  nonzero  elements  bringing  about  reduced  CPU  time. 

9.4.4.  Comparison  of  MIDAS/N  and  MIDAS/R 
Using  Skyline  Approach 

In  this  section,  the  efficiency  of  MIDAS/N  and  MIDAS/R  is  compared 
in  solving  equations  using  the  skyline  approach.  The  two  computer 
programs  SKYSOL  and  SKYSOLB  were  used  to  solve  the  two  sets  of 

equations.  The  comparison  of  results  is  given  in  Table  9.4.3. 

Equations  are  solved  for  different  cases  of  page  size  and  number  of 

pages.  Two  different  cases  (i)  20  pages  of  256  words,  and  (ii)  20  pages 
of  1024  words  are  used  for  comparison. 

The  following  points  are  observed  from  the  table.  MIDAS/N  used 
33.05  seconds  of  CPU  time  for  solving  1000  equations  with  half  band 
width  of  10  and  page  size  of  256  words,  whereas  MIDAS/R  for  solving  the 
same  equations  took  228.56  seconds.  Thus,  we  see  that  MIDAS/R  is  about 
8  times  slower  in  this  case.  For  page  size  of  1024  words,  MIDAS/R  is 
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Table  9.4.3  Comparison  of  MIDAS/ N  and  MIDAS/ R  Using 
Skyline  Approach 


Problem  details: 
Number  of  equations 
Half  band  width 
Skyline  height 


Page 

Si  ze 

Number  of 
Pages 

MIOAS/N 

MIDAS/R 

CPU 

NREAD 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

256 

20 

33.05 

340 

127 

16262 

228.55 

16103 

218 

12984 

1024 

20 

30.69 

70 

30 

16262 

119.00 

13970 

74 

12984 

Problem  details: 

Number  of  equations  : 
Half  band  width  : 
Skyline  height  : 

1000 

30 

30 

Page 

Si  ze 

Number  of 
Pages 

MIDAS/N 

MIDAS/R 

CPU 

NREAD 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

256 

20 

125.36 

1394 

480 

38688 

3138.66 

65602 

530 

32594 

1024 

20 

114.73 

337 

120 

38688 

1576.16 

31417 

191 

32594 
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about  4  times  slower  than  MIDAS/N.  The  number  of  writes  in  MIDAS/ R  is 
about  2  times  more  than  in  MIDAS/N,  and  the  number  of  reads  in  MIDAS/R 
is  very  high  compared  to  MIDAS/N.  We  could  attribute  this  high  value  of 
reads  to  the  nature  of  addressing  and  searching  used  in  MIDAS/R. 
MIDAS/N  uses  indexing  scheme  to  locate  the  data  whereas  MIDAS/R  uses 
hashing  scheme  which  uses  a  large  number  of  reads  and  searches  to  locate 
the  required  data.  Number  of  calls  to  MIDAS/N,  on  the  other  hand  were 
higher  than  in  MIDAS/R.  This  is  because,  MIDAS/N  uses  addresses  of 
diagonal  elements  to  locate  the  columns  of  a  skyline  matrix  which  is 
stored  in  a  single  row  vector.  MIDAS/N  is  required  to  locate  this 
address  before  accessing  the  skyline  vector.  MIDAS/R  does  not  require 
such  addresses,  since  skyline  vectors  are  stored  in  variable  length 
rows,  thereby  using  less  number  of  calls  to  MIDAS/R.  In  the  case  of  the 
second  set  of  equations  with  half  band  width  of  30,  similar  trends  of 
CPU,  NREAD,  NWRITE  and  NCALL  are  observed. 

Therefore,  from  the  above  results,  we  see  that  MIDAS/R  is 
inefficient  compared  to  MIDAS/N. 

9.4.5  Comparison  of  MIDAS/N  and  MIDAS/R 
Using  Hypermatrix  Approach 

Here,  the  efficiency  of  MIDAS/N  and  MIDAS/R  is  compared  in  solving 
equations  using  the  hypermatrix  approach.  The  two  computer  programs 
HYPSOL  and  HYPMDN  were  used  to  solve  the  two  sets  of  equations.  The 
comparison  of  results  is  given  in  Table  9.4.4.  Equations  are  solved  for 
different  cases  of  page  size  and  number  of  pages. 


Table  9.4.4  Comparison  of  NIDAS/N  and  NIDAS/R  Using 
Hypermatrix  Approach 


Problem  details: 

Number  of  equations  :  1000 

Half  band  width  :  10 

Submatrix  size  :  10*10 


Page 

Si  ze 

Number  of 
Pages 

MIDAS/N 

MIDAS/R 

CPU 

NREAD 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

256 

20 

248.10 

22698 

1001 

11487 

2720.87 

92312 

564 

12082 

1024 

20 

211.40 

6013 

339 

11487 

1623.00 

50678 

619 

12082 

Problem  details: 

Number  of  equations  : 
Half  band  width 
Submatrix  size  : 

1000 

30 

10*10 

Page 

Si  ze 

Number  of 
Pages 

MIDAS/N 

MIDAS/R 

CPU 

NREAD 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

256 

20 

486.02 

39545 

1326 

22939 

8207.61 

275060 

1157 

24117 

1024 

20 

411.42 

10370 

435 

22939 

3717.68 

115788 

1327 

24117 

The  following  points  are  observed  from  the  table.  MIDAS/N  uses 
248.10  seconds  of  CPU  time  to  solve  1000  equations  with  half  band  width 
of  10  and  page  size  of  256  words,  whereas  MIDAS/R  takes  2720.87  seconds 
of  CPU  time  to  solve  the  same  set  of  equations.  Thus,  MIDAS/R  is  about 
10  times  slower  than  MI0AS/N  in  this  case.  For  page  size  of  1024  words, 
MIDAS/R  is  about  8  times  slower  than  MIDAS/N.  Number  of  reads  in 

MIDAS/R  is  about  4  times  more  than  in  MIDAS/N  for  page  size  of  256 

words.  On  the  other  hand,  number  of  writes  in  MIDAS/R  is  about  2  times 
less  than  in  MIDAS/N  for  the  same  size.  For  page  size  of  1024  words, 
number  of  reads  in  MIDAS/R  is  about  8  times  more  than  in  MIDAS/N, 

whereas  number  of  writes  in  MIDAS/R  is  2  times  more  than  in  MIDAS/N. 
Number  of  calls  in  MIDAS/R  are  slightly  higher  than  in  MIDAS/N.  This  is 
because,  MIDAS/R  uses  2  call  statements  -  RDSGET  and  RDSM0D  to  modify 
data  whereas  MI0AS/N  uses  only  one  call  statement  RDSPUT  to  modify 
data.  Similar  trends  of  CPU,  NREAD,  NWRITE  and  NCALL  are  observed  for 
the  second  set  of  equations. 

Therefore,  from  these  results  we  can  see  that  MIDAS/R  is 

inefficient  compared  in  MIDAS/N. 


9.4.6  Performance  of  Memory  Management 
of  MIDAS/R 

As  mentioned  in  Chapter  6,  the  MIDAS/R  program  is  based  on 
modification  and  extension  of  the  RIM  program.  A  new  memory  management 
interface  was  added  to  assess  improvements  in  performance  of  the  RIM 
program.  Here,  a  comparison  of  performance  of  RIM's  built-in  memory 
management  system  and  the  performance  of  MIDAS/R  with  the  additional 
memory  management  is  made.  The  CPU  times  to  solve  1000  equations  are 
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used  to  compare  the  performance.  Table  9.4.5  shows  the  CPU  time  for 
various  size  of  RIM's  built-in  memory  management  scheme  and  additional 
memory  management  scheme.  Observe  from  the  table  that  the  CPU  time  does 
not  vary  considerably  by  increasing  the  total  memory  of  the  built-in 
|  memory  management  scheme  of  RIM.  This  indicates  that  the  RIM  program  is 

not  capable  of  utilizing  large  memory  of  the  computer  effectively.  By 
introducing  the  additional  memory  management  scheme  in  MIDAS/R  we  see 
that  CPU  time  reduces  considerably.  As  page  size  increased  from  256 
words  to  2048  words,  CPU  reduced  from  228.55  seconds  to  79.00  seconds 
for  RIM's  built-in  memory  of  9216  words.  Similar  trends  are  observed 
for  other  cases  of  memory  sizes.  Therefore,  we  see  that  memory 
management  plays  a  very  important  role  in  a  dynamic  environment  of 
engineering  applications.  Also,  memory  management  of  the  RIM  program 
can  be  substantially  improved. 

9.5  Evaluation  of  the  Computer  Program 
for  Structural  Design  Optimization 
- 'UsingMlDAS  - 

The  computer  program  for  structural  design  optimization  described 

in  Chapter  8  is  evaluated  here.  Evaluation  of  the  program  is  based  on 

several  criteria  (i)  capability  to  analyze  and  optimize  large  structural 

systems,  (ii)  modular  program  features,  (iii)  element  library,  (iv)  out- 

of-core  solution  schemes,  (v)  well  designed  database,  (vi)  database 

management  system,  and  (vii)  performance  of  the  computer  program.  The 

general  purpose  capability  of  the  program,  modular  program  features, 

element  library  and  out-of-core  solution  schemes  used  in  the  program 

are  already  described  in  Chapter  8.  Based  on  the  evaluation 


Table  9.4.5  Performance  of  Memory  Management  of  NIDAS/R 


Number  of  equations  :  1000 

Half  band  width  :  10 


Total  Memory  of 
RIM's  Built-in  M.M  CPU 


1597.33 


With  Additional  M.M.  Interface 


Page  Size 


20480 


81920 


163840 


1542.53 


1514.00 


1607.69 


No.  of  Pages 


228.1 
115.6 
79.5 


221.5 
112.3 
74.5 


218.0 
115.7 
80.9 


criteria  (i)  to  (iv),  the  program  is  well  designed  and  satisfied  the 


requirements.  Also,  the  program  uses  well  designed  database  and 
database  management  system  discussed  in  Chapter  7  and  6,  respectively. 
Therefore,  no  further  discussion  on  criteria  (i)  to  (vi)  is  made  here. 
Detailed  evaluation  of  the  performance  of  the  computer  program  is  based 
on  several  example  problems  described  in  Section  8.4. 

The  performance  of  the  program  is  measured  by  noting  parameters 

such  as  CPU  time,  number  of  reads  and  writes  made  on  physical  database, 

and  number  of  calls  made  to  the  database  management  system.  These 
parameters  are  noted  while  solving  problems  (i)  ten  bar  truss  (ii) 
twenty-five  bar  truss,  (ii)  forty-seven  bar  truss,  (iv)  seventy-two  bar 
truss,  (v)  one  hundred-eight  bar  truss,  and  (vi)  two  hundred  bar 
truss.  The  data  of  these  parameters  are  collected  and  given  in  Tables 
9.5.1  to  9.5.6.  Tables  show  these  parameters  for  items  -  input  and 
preprocessing  step  (1),  finite  element  analysis  (2),  design  sensitivity 
analysis  (3),  and  design  change  computation  done  by  the  program  IDESIGN3 
(4).  The  tables  show  the  CPU,  NREAD,  NWRITE  and  NCALL  for  both  the 
total  run  for  all  iterations  required  for  optimization  and  for  each 
iteration  of  the  optimization  computation.  Also,  the  tables  show  the 
total  -  CPU,  NREAD,  NWRITE  and  NCALL  for  the  complete  optimal  design 
computation.  The  CPU  time  to  solve  the  problems  using  the  computer 
program  are  compared  with  the  results  given  by  Thanedar,  Park  and  Arora 
1985. 

The  following  points  are  observed  from  these  tables.  The  CPU 

required  to  solve  the  various  problems  using  the  present  computer 


Table  9.5.1  Summary  of  Evaluation  Parameters  for  Ten  Bar  Truss 


Item 

No. 

For  Final  Solution 

For  each  Iteration 

CPU 

NREAD 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

1 

18.23 

352 

106 

419 

18.23 

352 

106 

419 

2 

15.03 

165 

22 

2299 

1.36 

15 

1 

209 

3 

18.42 

220 

121 

1419 

1.67 

10 

11 

129 

4 

34.61 

3.14 

Total 

86.29 

737 

249 

4137 

CPU  time 

i  from  Thanedar, 

Park  and  Arora 

(1985): 

5.5  sec. 

Table  9.5 

i.2  Sunmary  of  Evaluation  Parameters  for  Twenty  Five 

Bar  Truss 

Item 

For  Final  Solution 

For  each  Iteration 

No. 

CPU 

NREAD 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

1 

18.37 

356 

108 

1005 

18.67 

356 

108 

1005 

2 

34.37 

315 

150 

7365 

2.29 

21 

10 

491 

3 

32.89 

390 

390 

4199 

2.19 

26 

26 

280 

4 

52.27 

3.48 

Total 

137.9 

1061 

648 

12569 

CPU  time  from  Thanedar, 

Park  and  Arora 

(1985): 

7.4  sec. 

Table  9.5.3  Sunnary  of  Evaluation  Parameters  for  Forty  Seven  Bar  Truss 
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I 

vj 

a 
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Item 

No. 

For  Final  Solution 

For  each  Iteration 

CPU 

NREAD 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

1 

21.46 

359 

122 

2405 

21.46 

359 

122 

2405 

2 

20.08 

174 

90 

5862 

3.34 

29 

15 

977 

3 

47.52 

312 

426 

7980 

7.92 

52 

71 

1330 

4 

51.30 

8.55 

Total 

140.36 

845 

638 

16247 

CPU  time 

!  from  Thanedar, 

Park  and  Arora 

(1985): 

64.0  sec. 

Table  9.5.4  Summary  of  Evaluation  Parameters  for  Seventy  Two 

Bar  Truss 

Item 

For  Final  Solution 

For  each  Iteration 

No. 

CPU 

NREAD 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

1 

22.14 

360 

127 

4862 

22.14 

360 

127 

4862 

2 

83.99 

527 

340 

25483 

4.94 

31 

20 

1499 

3 

56.25 

424 

696 

11208 

5.11 

38 

63 

1018 

4 

69.63 

4.97 

Total 

231.01 

1331 

1163 

41553 

CPU  from 

Thanedar, 

Park 

and  Arora  (1985) 

:  29.3 

sec . 
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Table  9.5.5  Sumary  of  Evaluation  Parameters 
for  One  Hundred  Eight  Bar  Truss 


Item 

No. 

For  Final  Solution 

For  each  Iteration 

CPU  1 

NREAD 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

1 

25.96 

397 

136 

9107 

25.96 

397 

136 

9107 

2 

226.91 

1320 

870 

67620 

7.56 

44 

29 

2254 

3 

379.84 

1610 

3128 

60352 

12.66 

53 

104 

2011 

4 

230.75 

7.69 

Total 

863.46 

3327 

4134  137079 

Table  9. 

5.6  Sunmary  of  Evaluation  Parameters  for  T\*o  Hundred 

Bar  Truss 

Item 

For  Final  Solution 

For  each  Iteration 

No. 

CPU 

NREAD 

NWRITE 

NCALL 

CPU 

NREAD 

NWRITE 

NCALL 

1 

44.97 

601 

166 

44081 

44.97 

601 

166 

44081 

2 

412.41 

2070 

1530 

147870 

13.74 

69 

51 

4929 

3 

1210.21 

27450 

9810 

135960 

40.34 

915 

327 

4532 

4 

330.00 

11.00 

Total 

2000.5 

30121 

11506 

327911 

program  and  the  one  used  in  the  reference  are  much  different.  The 
program  used  in  Thanedar,  Park  and  Arora  (1985)  performs  finite  element 
analysis  and  design  sensitivity  computation  using  only  the  available 
memory  in  the  computer.  No  out-of-core  data  storage  is  used  by  the 
program.  Whereas  the  computer  program  developed  here  uses  the  database 
and  database  management  system  described  earlier.  Therefore,  the  CPU 
time  taken  to  solve  these  problems  are  high  compared  with  the  results 
given  in  the  reference,  as  expected.  For  instance,  CPU  time  of  86.29 
seconds  is  used  by  the  program  compared  to  5.5  seconds  used  by  the 
program  given  in  the  reference.  Similar  trends  are  observed  from  the 
table  for  other  problems. 

Several  other  points  are  observed  from  the  table.  CPU  time,  NREAD, 
NWRITE  and  NCALL  increase  as  the  size  of  problem  increase  as  expected. 
CPU  time,  NREAD,  NWRITE  and  NCALL  for  input  and  preprocessing  of  data  is 
small  compared  to  those  of  finite  element  analysis,  and  design 
sensitivity  computation.  However,  these  values  are  very  high  compared 
to  one  iteration  of  finite  element  analysis  and  design  sensitivity 
computation.  One  of  the  reasons  is  extensive  preprocessing  of  data  done 
before  assembly  of  large  matrices  and  solution  of  equations.  This 
preprocessing  has  enabled  us  to  achieve  efficient  assembly  of  matrices 
and  solution  of  equations.  Another  reason,  can  be  attributed  to  the  use 
of  hypermatrix  scheme  in  the  finite  element  analysis  and  design 
sensitivity  computation.  The  hypermatrix  scheme  uses  large  amount  of 
intermediate  information  such  as  element  numbers  contributing  to 
submatrices,  ncinull  partition  numbers  for  assembly  and  other 
computations.  It  requires  lengthy  programming  logic  and  use  of  database 


to  generate  such  data.  Thus,  the  input  and  preprocessing  step  consumes 
more  CPU  time  to  generate  the  required  data. 

Further,  note  that  as  number  of  calls  made  to  database  management 
system  increases,  so  does  the  CPU  time.  This  indicates  that  DBMS 
consumes  enormous  CPU  time  which  is  much  higher  than  the  CPU  time 
required  for  actual  computation.  Therefore,  it  is  very  important  to 
reduce  the  number  of  calls  made  to  DBMS.  Several  ways  to  achieve  this 
are  (i)  use  as  much  incore  data  storage  as  possible,  (ii)  redesign 
relations  so  that  number  of  accesses  required  to  retrieve  necessary  data 
is  minimum,  (iii)  include  starting  and  ending  row  numbers  in  the  data 
manipulation  routines  to  store  and  retrieve  relations,  (iv)  use  adjoint 
sensitivity  analysis  method  and  (v)  use  skyline  approach  to  design  the 


computer  program. 


in  design.  Important  components  required  to  build  a  computer-aided 
structural  design  system  are  described.  Need  for  a  good  data  management 
system  is  emphasized.  Users  of  computer-aided  structural  design  system 
are  identified  and  their  requirements  are  described. 

A  study  of  database  management  concepts  applicable  to  finite 
element  analysis  and  structural  design  optimization  is  conducted.  This 
study  is  essential  since  the  data  managements  concepts  are  relatively 
new  to  engineering  community.  Definition  of  various  terminologies  is 
given  and  described  with  reference  to  examples  from  finite  element 
analysis  and  optimization  data.  Hierarchical,  network,  relational  and 
numerical  data  models  are  described.  The  advantages  and  disadvantages 
of  these  models  are  discussed.  Relational  and  numerical  data  models  are 
found  to  be  appropriate  for  structural  data  organization.  The  concept 
of  normalization  of  data  is  described.  This  concept  provides  certain 
guidelines  to  group  different  data  items  to  form  associations.  Global 
and  local  database  concepts  are  described  and  their  use  of  design 
optimization  is  brought  out. 

A  methodology  to  design  a  structural  design  database  is  proposed. 
Up  until  now,  no  such  methodology  has  been  used  for  data  organization  of 
existing  finite  element  programs.  No  scientific  database  management 
techniques  were  available  at  the  time  those  programs  were  developed. 
Three  levels  of  data  organization  —  conceptual  internal  and  external 
are  suggested  for  structural  design  databases.  Data  organization  at 
the  conceptual  level  represents  inherent  characteri sti cs  of  data 
regardless  of  whether  or  not  database  management  software  available 
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supports  such  organization  directly.  Various  steps  are  identified  to 
develop  a  conceptual  data  model.  Methodology  for  including  vector  and 
matrix  data  in  the  conceptual  data  model  is  described.  A  methodology 
for  constructing  an  internal  model  is  proposed.  The  internal  model  aims 
to  store  the  structural  design  data  in  an  efficient  way.  Considerations 
for  reducing  storage  space  and  data  access  time  are  discussed. 
Normalization  of  data  is  suggested  to  avoid  various  anomalies  in  storage 
operation.  A  method  for  developing  an  external  model  is  given.  An 
external  data  model  enables  us  to  provide  data  to  several  application 
programs  depending  on  their  needs.  One  of  the  important  aspects  in  the 
design  of  database  for  structural  analysis  matrix  data.  A  methodology 
is  developed  to  store  large  matrix  data  in  the  database.  Various  types 
of  large  matrices  --  square,  triangular,  banded,  hypermatrix,  and 

skyline  matrix  —  are  identified  and  their  characteristics  are 
studied.  Various  aspects  like  storage  space,  processing  sequence, 

matrix  operations,  page  size,  flexibility  of  modification,  etc.,  are 

considered  to  develop  suitable  storage  schemes.  A  numerical  model  is 
developed  to  represent  large  order  matrix  data.  Finally,  an  algorithmic 
model  is  proposed  to  deal  with  storage  and  computation  efficiency 

aspects  required  for  structural  design  optimization  programs. 

A  proposal  to  develop  a  database  management  system  for  structural 
analysis  and  optimal  design  is  made.  Components  required  for  a  good 
database  management  system  are  identified.  Some  important  components  of 
the  database  management  system  are  —  languages,  command  processors, 
addressing  and  searching,  file  definition  and  file  operation,  memory 


management  and  security  routines.  Requirements  of  data  definition  and 
data  manipulation  languages  are  formulated.  Query  language  is  proposed 
for  an  interactive  user  of  a  database.  A  syntax  (grammer)  for  these 
languages  is  given.  A  survey  of  existing  database  management  systems  is 
conducted.  Requirements  of  a  database  management  system  are  formulated. 

Implementation  of  a  database  management  system  --  MIDAS  was  done. 
MIDAS  program  has  two  subsystems  —  MIDAS/R  and  MIDAS/N.  MIDAS/R  is 
based  on  relational  model  of  data  and  MIDAS/N  (Shyy,  1985)  is  based  on 
numerical  model  of  data.  MIDAS/R  relieves  the  burden  of  managing  data 
for  application  programmers  by  providing  user-friendly  application 
commands.  The  program  has  sophisticated  interactive  commands  to  query 
the  database.  Relations  can  be  defined  and  manipulated  using  data 
definition  and  data  manipulation  commands  of  MIDAS/R.  Interactive 
commands  of  MIDAS/R  can  also  be  used  to  define  and  manipulate  relations 
in  a  database.  MIDAS/R  has  capability  to  store  any  number  of  relations 
in  a  database.  Numerical  database  management  system  —  MIDAS/N  has 
capability  to  store  matrix  data  of  finite  element  analysis  and 
optimization  programs. 

A  database  is  designed  to  store  data  of  finite  element  analysis  and 
structural  design  optimization.  The  design  is  completed  in  three  phases 
using  the  methodology  developed.  Conceptual  data  model  is  designed  by 
identifying  entities,  entity  keys  and  domains  and  forming  elementary 
relations.  Internal  data  model  is  designed  based  on  needs  of 
computation  process  and  normal i zation  procedures.  This  model  is  used 
for  implementation  of  database.  Also,  some  relations  are  suggested  to 


serve  as  an  external  data  model.  The  methodology  of  database  design  is 
evaluated  in  view  of  the  actual  database  design. 

A  computer  program  is  developed  for  finite  element  analysis  and 
design  sensitivity  analysis.  The  program  has  several  modules  which  are 
functionally  independent.  The  program  uses  the  database  and  the 
database  management  systems  -  MIDAS/R.  The  program  is  capable  of 
optimizing  general  structural  design  problems.  Capabilities  of  the 
program  —  element  library,  hypermatrix  assembly,  out-of-core  solution 
of  equations,  imposing  stress  and  displacement  constraints  are 
explained.  The  modules  used  in  the  program  are  described.  A  number  of 
example  problems  are  solved  using  the  program. 

Finally,  the  database,  the  database  management  system  -  MIDAS,  and 
the  computer  program  for  structural  design  optimization  are  evaluated. 
The  database  is  evaluated  using  several  criteria.  The  data  definition, 
data  manipulation  and  query  languages  of  MIDAS  are  evaluated.  Computer 
programs  for  out-of-core  solution  of  equations  using  skyline  and 
hypermatrix  approaches  are  developed.  The  performance  of  MIDAS/R  and 
MIDAS/N  is  determined.  The  efficiency  of  both  the  systems  are 
compared.  The  computer  program  for  structural  design  optimization  is 
eval uated. 

10.2  Discussion 

The  study  answers  several  problems  facing  data  management  in  finite 
element  analysis  and  structural  design  optimization  computations.  The 
following  questions  were  addressed  in  the  study:  (i)  how  a  database  has 
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to  be  organized?  (ii)  what  kind  of  information  is  to  be  stored?  (iii) 
what  kind  of  database  management  system  is  suitable?  (iv)  how  data  is 
manipulated?  and  (v)  /aw  various  finite  element  analysis  and  design 
optimization  applications  use  the  data?  Answers  to  these  questions  were 
not  available,  since  only  a  few  research  studies  had  been  made  on  the 
topic.  Thus,  we  were  faced  with  the  problem  of  how  to  answer  these 
questions.  In  this  regard,  sophisticated  techniques  were  available  to 
organize  data  of  business  applications.  Our  next  question  was,  is  it 
possible  to  use  those  techniques  to  organize  data  of  engineering 
applications?  Soon  it  was  realized  that  data  of  business  applications 
were  of  different  nature  than  the  data  of  engineering  applications.  But 
the  question  arose  as  to  whether  engineering  data  could  be  similarly 
modeled?  If  so,  do  the  structural  design  databases  require  different 
considerations  from  database  of  business  applications?  These  questions 
were  not  adequately  answered  previously.  Several  different  approaches 
had  to  be  taken;  for  example,  a  study  of  database  management  concepts, 
use  of  available  database  management  systems,  and  development  of  special 
structural  design  database  management  systems. 

Therefore,  an  attempt  was  made  to  study  all  the  relevant  data 
management  concepts.  The  concepts  that  were  found  applicable  were 
described  with  reference  to  examples  for  finite  element  analysis  and 
design  optimization  data.  The  database  management  approach  presented  in 
the  study  offers  solution  to  many  of  these  problems.  The  study  shows 
how  data  of  finite  element  analysis  and  optimization  can  be  organized 
using  various  data  models.  Relational  and  numerical  models  were  found 


.v.v .  «\  /.V.  a.  -\  s.  ^ r.f-  - .  • 


to  represent  all  the  characteristics  of  structural  design  data  and 

therefore  they  were  selected  for  detailed  study.  Questions  were  posed 
as  to  how  to  decide  what  data  items  have  to  be  grouped  together?  In 

particular,  using  a  relational  model,  how  do  we  determine  what  relations 
are  needed?  and  what  their  attributes  should  be?  It  was  shown  that 
normalization  of  data  provides  certain  guidelines  to  group  the  general 
data  items.  It  was  realized  that  the  normal  form  of  data  did  not 

suggest  schemes  to  group  data  of  large  matrices.  Further,  the  concept 
of  global  and  local  databases  was  found  useful  in  organizing  iterative 
data  of  structural  design  optimization. 

After,  we  formulated  the  database  management  concepts  for  computer- 
aided  structural  design  optimization,  the  next  question  was  how  to 
design  a  database?  Is  it  possible  to  develop  a  methodology  for 

designing  a  database  for  structural  analysis  and  design?  If  possible 
how  do  we  begin  to  develop  a  methodology?  Are  the  methodologies  used  in 
business  application  suitable  for  our  purpose?  If  not,  what  aspects 
should  be  considered  in  developing  a  methodology  for  structural  design 
databases?  A  methodology  was  proposed  considering  several  features  and 
requirements  of  finite  element  analysis  and  structural  design 
optimization  applications.  Methodology  used  relational  and  numerical 
data  models  for  designing  a  database.  Special  consideration  was  given 
to  incorporate  large  matrix  data  into  the  database.  A  database  was 
designed  using  the  methodology.  This  database  was  used  for  actual 
implementation  of  the  computer  program  for  structural  design 
optimization.  The  methodology  was  evaluated  to  see  if  it  was  suitable 


to  design  databases  of  structural  optimization  applications.  It  was 
realized  that  the  methodology  was  to  some  extent  dependent  on  the  way  in 
which  characteristics  of  data  are  analyzed.  Detailed  analysis  of 
entities,  domains  and  functional  dependencies  were  needed  which  was 
sometimes  difficult  to  make.  But,  in  general  the  methodology  enabled  us 
to  design  a  well  organized  database  for  structural  design  application. 

Later,  in  the  study,  we  dealt  with  the  need  of  a  software  for 
database  management.  What  kind  of  database  management  program  is 
suitable?  Is  it  possible  to  use  an  existing  DBMS  or  develop  a  new 
database  management  system?  What  modifications  are  required  to  existing 
DBMS  so  that  it  can  be  used  in  structural  design  application?  These 
questions  were  tackled  by  a  detailed  study  of  requirements  of  a  DBMS. 
It  was  realized  that  data  definition  and  data  manipulation  languages 
play  an  important  role  in  providing  a  communication  like  between 
designer  and  computer  system.  MIDAS  program  for  database  management  was 
developed.  The  program  was  able  to  organize  both  relations  and  matrix 
data.  This  program  was  found  to  meet  most  of  the  requirements  of  a 
DBMS. 

A  finite  element  analysis  and  structural  design  optimization 
program  was  developed  using  the  database  and  the  database  management 
system  MIDAS.  The  program  was  able  to  solve  complex  structural  design 
problems.  Modular  program  design,  element  library,  hypermatrix  assembly 
scheme,  out-of-core  solution,  stress  and  displacement  constraint 
capabilities  of  the  program  were  found  very  useful.  The  program  was 
developed  to  find  out  the  suitability  of  the  database  design,  efficiency 


of  the  database  management  system,  and  efficiency  of  the  structural 
design  optimization  program.  Also,  several  different  types  of  equation 
solvers  were  developed  using  skyline  and  hypermatrix  approaches 
incorporating  MIDAS  for  out-of-core  solution.  It  was  realized  that 
performance  of  DBMS  needs  careful  consideration  in  designing  a  DBMS  for 
engineering  applications. 


10.3  Conclusions 

Important  conclusions  of  the  study  are  listed  below. 

1.  The  study  has  shown  that  computer-aided  design  optimization  of 
complex  structural  systems  can  be  attempted  by  integrating 
finite  element-based-optimal  design  methods  and  computer-science 
methods  into  a  computer-based  system  containing  a  database,  a 
program  library  and  man-machine  communication  link. 

2.  The  study  has  shown  that  database  management  plays  a  very 
important  role  in  developing  a  computer-aided  design  system. 
Several  problems  of  data  organization  in  finite  element  analysis 
and  optimization  applications  can  be  overcome  by  providing 
sophisticated  database  management  systems. 

3.  The  study  has  shown  that  various  database  management  concepts 
are  applicable  to  data  organization  of  structural  design 
problems.  Several  concepts  such  as  relational  and  numerical 
data  model  are  useful  to  organize  tabular  and  matrix  type  of 
data  used  in  computation.  Suitability  and  drawbacks  of  these 
concepts  are  explained. 


4.  The  methodology  developed  for  designing  a  database  for 
structural  design  application  is  useful  and  this  methodology 
will  replace  the  intuitive  way  of  data  organization  in  finite 
element  analysis  and  optimization  programs.  The  methodology,  to 
a  certain  extent,  is  dependent  on  the  analysis  of 
characteristics  of  the  data.  Such  analysis  of  complex 
structural  design  data  is  not  easy.  Methodology  to  organize 
both  tabular  type  of  data  and  large  matrix  data  was  very 
useful.  More  study  is  needed  to  consolidate  the  methodology 
developed  herein. 

5.  Formulation  of  requirements  of  a  database  management  system  has 
enabled  us  to  develop  and  use  proper  database  management  system 
for  structural  design  optimization.  Formulation  of  requirements 
of  data  definition,  data  manipulation  and  query  languages  has 
helped  in  providing  a  good  communication  link  between  computer 
and  application  programmer. 

6.  A  suitable  database  management  system  was  implemented  by 
selecting,  modifying  and  extending  an  existing  database 
management  system  to  meet  the  requirements  of  structural  design 
applications.  This  implementation  has  enabled  us  to  explain 
suitability  and  drawbacks  of  existing  DBMS. 


7.  The  database  designed  using  the  methodology  is  capable  of 
storing  structural  design  data.  The  database  is  well  organized 
and  meets  the  requirements  of  finite  element  analysis  and 
structural  design  optimization  applications.  This  design  of 
database  has  enabled  us  to  demonstrate  the  use  of  database 
design  methodology.  Our  objective  of  having  a  well  designed 
database  for  computer-aided  structural  design  was  met. 

8.  Implementation  of  a  finite  element  program  and  structural  design 
optimization  program  using  the  database  and  database  management 
system  has  shown  that  computer-aided  design  of  complex 
structural  systems  can  be  attempted.  It  was  realized  such 
systems  can  be  developed  easily  and  quickly  with  the  use  of 
database  and  database  management  systems. 

9.  Evaluation  of  database  management  system  has  indicated  that  some 
compromise  has  to  be  made  for  the  use  of  sophisticated  DBMS  in 
terms  of  inefficiency  in  computer  CPU  time.  More  study  is 
needed  to  improve  the  efficiency  of  DBMS  for  engineering 
appl ications . 

10.4  Scope  for  Future  Work 

This  extensive  study  on  database  management  for  computer-aided 


structural  design  optimization  has  shown  that  there  is  great  potential 
for  future  work.  Several  areas  are  suggested  for  extending  this  work. 


1.  Develop  a  more  sophi sticated  database  management  system  that  is 
capable  of  dealing  with  relational  and  numerical  data  model 
simul taneously . 

2.  Develop  a  detailed  conceptual  data  model  by  considering  not  only 
the  basic  association  between  data  but  also  processing  sequence 
of  computation  to  obtain  a  complete  theoretical  analysis  of 
structural  design  data. 

3.  Improve  the  efficiency  of  database  management  system  by 
enhancing  the  memory  management  schemes. 

4.  Develop  a  methodology  to  integrate  several  existing  finite 
element  analysis  programs  into  a  common  database.  A  more 
detailed  study  of  external  model  is  required. 

5.  Methodology  for  integrating  several  databases  for  existing 
finite  element  analysis  programs  needs  to  be  developed.  Network 
of  databases  appears  to  be  very  useful  in  engineering 
appl ications . 

6.  Study  how  a  database  can  be  utilized  in  parallel  processing  of 
data  in  structural  analysis  and  design  optimization. 

7.  Use  of  database  and  database  management  system  in  mini-  and 
micro  computer  systems  needs  to  be  studied. 

8.  Use  of  database  and  database  management  system  in  finite  element 
mesh  generation  and  mesh  display  needs  further  study. 
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An  algorithm  for  determining  transitive  closure  from  a  given 

connectivity  matrix  C  is  as  follows: 

1.  Form  matrix  J  with 

J(  i  ,i )  =  0  for  1  <  i  <  n 
=  1  for  i  *  j 

2.  Form  modified  connectivity  matrix  CC 

with  CC(i  ,j)  =  C(i  ,j)  1  <  i  <  n 

1  <  j  <  n 

and  CC(  i  ,i )  =  0 

3.  DO  i  =  l,n 

DO  k  =  1  ,n 

DO  j  =  1  ,n 

If  If  (CC(i  ,j) •EQ-l«AND«CC(j,k) -EQ-1)C( i  ,k)  =1 
End  DO  loop 

4.  Remove  erroneous  dependencies  that  were  derived  from  the  situation 
N-  +  Nj  +  Ni 

5.  IS  new  matrix  C  obtained?  If  no,  stop 

6.  Form  modified  connectivity  matrix  (as  in  step  2)  using  CC  matrix 
derived  in  step  3 

7.  Go  to  step  3 


8.  End 
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BNF  DESCRIPTION  OF  THE  PROPOSED 
DATA  DEFINITION  LANGUAGE 
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<letter> ::  =  A  |  B  |  C  | . |Z 

<digits>: :  =  1 12  j . 9|0 

<basic  symbols::  =  <letters> |<digits> 

<string>::  =  <any  sequence  of  basic  symbol s> 

<variable>::  =  <simple  variable>|<subscripted  variable> 

<simple  variable>::  =  <identifier> 

<identi fier> : :  =  <letter>  | <identiferxl etter  or  digit> 
<subscripted  variable>::  =  <identifer>[<subscript  list>] 
<subscript  list>::  =  <fortran  subscript  1 i st > 

<empty>::  =  <null  string  of  symbol s> 

<unsigned  integer>::  =  <digit> |<unsigned  integerxdigit> 

<data  definition  statement>::  = 

<database  definition  statement> | 
<database  user  specification  statement^ 
<database  definition  statement> | 
<relation  data  definition  statement>| 


<database  status> 

<database  definition  error  code> 


$ 
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<database  name?::  =  '<name>‘  j<variable> 

<database  heirarchy>::  =  '<heirarchy  type? ' |<variable> 

<hierarchy  type>::  =  GLOBAL] LOCAL 
<name>::  =  <letter?<string? 

<database  status>::  =  '<status  type?' |<variable? 

<status  type>::  =  PERMANENT! TEMPORARY 
<database  definition  error  code>::  =  <variable> 

<database  user  identi fication  statement>: :  = 

reserved  procedure  DBUSER> 

(<database  user  identification  parameter  part>) 
<database  user  identification  parameter  part>::  = 

<database  name?, 

<database  user  type?, 

<database  access  type>,  <password>, 

<user  identification  error  code> 

<database  user  type>::  =  '<user  type> ' |<variable> 

<user  type>:  =  OWNER | USER 

<database  access  type>::  =  *<access  type> ' |<variable> 

<access  type>::  =  READ | MOD  I FY 
<password>::  =  <letterxstring> 

<user  identification  error  code>::  =  <variable> 


<data  set  definition  statement?::  = 


V  V  .*  / 


•(reserved  procedure  DSDEFN> 

(<dataset  definition  parameter  part>) 


<data  set  definition  parameter  part>::  = 

<database  name>, 

<dataset  name>, 

<dataset  type>, 

<data  item  row  size>, 

<data  item  column  size>, 

<data  set  definition  error  code> 

<data  set  name>::  =  ' <name> '  |<variabl e> 

<data  set  type>::  =  '<type  speci fication> '  j<variable> 

<type  specifiation>: :  =  I  NT | REAL | DOUB 

I VEC | RVEC  j  DVEC 
IMAT|RMATjDMAT 

(data  item  row  sizes:  =  (size> |(empty> | VAR 
(data  item  column  size::  =  (si ze> j(empty> | VAR 
(size>::  =  (unsigned  integer> |(variable> 

(data  set  definition  error  code>::  =  (variable> 

(relation  definition  statements:  = 

(reserved  procedure  DRLDFN> 

((relation  definition  parameter  part>) 
(relation  definition  parameter  part>::  = 

(database  name>, 

(relation  name>, 

(attribute  name  array>. 


attribute  type  array>, 

<attribute  row  size  array?, 
<attribute  column  size  array?, 
<attribute  key  specification  array>, 
crelation  definition  error  code> 


<relation  name>::  =  '<name>' |<variable> 

<attribute  name  array>::  =  '<name  array>‘ |<variable> 

<name  array>::  =  <name> |<name><name  array> 

<attribute  type  array>::  =  '<type  specification  array>' |<variable> 

<type  specification  array>::  =  <type  speci fication> 

|<type  specificationxtype  specification  array> 
<attribute  row  size  array>::  =  <variable> 

<attribute  column  size  array>::  =  <variable> 

<attribute  key  specification  array>::  = 

<key  specification  array> |<variable> 

<key  specification  array>::  =  KEY|KEY<key  speci fication> |<empty> 
<relation  definition  error  codex:  =  <variable> 

<data  definition  termination  statement>::  = 

<reserved  procedure  DSEND> 

(<data  definition  termination  parameter  part>) 
<database  definition  parameter  part>::  =  <empty> 

<data  redefinition  statement?::  = 

<reserved  procedure  DSRDFN? 

(<data  redefinition  parameter  part?) 

<data  redefinition  parameter  part?::  = 


<data  set  definition  parameter  part> 
|<relation  definition  parameter  part> 
|<numerical  data  definition  parameter  part> 
<matrix  data  definition  statements:  = 

<reserved  procedure  DSMATX> 

(<matrix  data  definition  parameters  part>) 
<matrix  data  definition  parts:  = 

<database  name> 

<matrix  identi fication> 

<matrix  characteristics> 

<matrix  definition  error  code> 

<matrix  identi fication> : :  =  1 <name> ' |<variable> 

<matrix  characteristics>: :  = 

'SQUARE' ,  <$.  Detail s> | 

'BANDED' ,  <B.  Detail s> | 

' riYPERMATRIX'  ,  <H.  Detai 1 s> | 

'SKYLINE,  <K.  Detail s>  | 

'SPARSE',  <P.  Detail s> 

<S.  Detai lss:  =  <matrix  storage  type> 

<matrix  ordering>, 

<matrix  size>, 

<empty>,  <empty>, 

<empty>,  <empty>, 

<empty>,  <empty> , 

cmatrix  storage  type>::  =  'cmatrix  storage  string>' |<variable> 


<matn‘x  storage  string>::  =  UPPER | LOWER | FULL 

<matrix  ordering>::  =  '<matrix  ordering  string> ' |<variable> 

<matrix  ordering  string>::  =  ROW | COLUMN 

<matrix  size>::  =  <row  size> ,<col umn  size> |VAR,<column  size> 

row  si ze> , VAR | VAR, VAR 
B.  Details>::  =  <matrix  storage  type>, 

<matrix  ordering>, 

<matrix  size>, 

<matrix  band  size>, 

<matrix  band  size>::  =  <number  of  upper  codiagonal s>, 

<number  of  lower  codiagonal s> 

<number  of  upper  codiagonal s>: :  =  <unsigned  integer> 

<number  of  lower  codiagonal s> : :  =  <unsigned  integer> 

<H.  Details>::  =  <matrix  storage  type> 

cmatrix  ordering>, 

<matrix  size>, 

<submatrix  size> 

<submatrix  size>::  =  row  si ze> |<variabl e> ,<col umn  size> |<variable> 
<K.  Oetai 1 s> : :  =  <empty>, 

<empty>, 

<matrix  size>, 

<skyline  definition> 

<skyline  definition> : :  =  <array  of  skyline  height> 

<P.  Detail s>::  =  <empty>. 


<empty> 


cmatrix  size>, 
<empty> ,<empty> 
<empty> ,<empty> 


■ 


Note:  1)  Vertical  bar  |  denotes  options  for  choosing  items  to  the  left 
of  the  bar  or  to  the  right  of  the  bar 

2)  [  ]  indicate  items  within  it  are  optional 

3)  <x>::  =  <y>  |  <x><z>  denotes  a  recursive  statement,  x  is 
used  repeatedly 

4)  1  '  indicates  items  within  it  taken  as  data 
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<Data  manipulation  statements:  = 
<database  open  statement> 

<database  close  statement 
<data  retrieval  statement> 

<data  append  statement 
<data  modify  statement> 

<data  delete  statement> 

<data  copy  statement 
<matrix  retrieval  statement> 
<matrix  append  statement 
<matrix  modify  statement> 

<matrix  delete  statement> 

<matrix  copy  statement 
<database  open  statements:  * 

creserved  procedure  DB0PEN> 
(<database  open  parameter  part> 
<database  open  parameter  parts:  = 
<database  name>, 

<database  hierarchy> 

<database  open  error  code> 
<database  open  error  code>::  =  <variable> 
<database  close  statement>::  = 

<reserved  procedure  DBCL0S> 
(<database  close  statement) 
<databare  close  statement>::  = 


<database  name> 


<database  hierarchy> 

<database  close  error  code> 

<data  retrieval  statement : :  = 

<reserved  procedure  DSGET> 

(<data  retrieval  parameter  part>) 

<data  retrieval  prarmeter  part>::  = 

<database  name>, 

<data  set  name> | <rel ation  name>, 

< i dent i fication  number> |<empty> , 

<user  buffer>, 

<data  manipulation  error  code> 

<identi fication  number>::  =  <tuple  number>|<row  number> 

<tuple  number>::  =  <unsigned  integer> |<variable> 

crow  number>::  =  cunsigned  integer> |<variable> 

cuser  buffer>::  =  <variable> 

cdata  manipulation  error  code>::  =  <variable> 

cdata  append  statement>::  = 

creserved  procedure  DSPUT> 

(cdata  append  parameter  part>) 
cdata  append  parameter  part>::  = 

cdata  retrieval  parameter  part> 
cdata  modify  statements:  = 

creserved  procedure  DSM0D> 

(cdata  modify  parameter  part>) 


i 


<data  modify  parameter  part>::  = 

<data  retrieval  parameter  part> 

<data  delete  statement>::  = 

<database  name>, 

<data  set  name> |<relation  name> , 
cidenti fication  number> |<empty>, 

<data  manipulation  error  code> 

<data  copy  statement^:  = 

<reserved  procedure  DSC0PY> 

(<data  copy  parameter  part>) 

<data  copy  parameter  part>::  = 

<database  name-copy  from>, 

<data  set  or  relation  name-copy  from> 

<database  name-copy  to> 

<data  set  or  relation  name-copy  to> 

<data  manipulation  error  code> 

<database  name-copy  from>::  =  <database  name> 

<data  set  or  relation  name-copy  from>::  =  <data  set  name>  | < rel ation 
name> 

<database  name-copy  to  >::  =  <database  name> 

<data  set  or  relation  name  -  copy  to>::  =  <data  set  name>  |<rel ation 


name> 


<data  manipulation  error  code>::  =  <variable> 
<matrix  retrieval  statement>::  = 


<reserved  procedure  MTGET> 

(<matrix  retrieval  parameters  part>) 

<matrix  retrieval  parameter  part>::  =  <database  name> 
<matrix  identification^ 

<row  number> ,[<col umn  number>], 

|<column  number> ,[<row  number>], 

|cempcy> ,<empty> , 

<user  bu!'er>, 

<matrix  manipulation  error  code> 

<matrix  manipulation  error  code>::  =  <variable> 
<matrix  append  statements:  = 

<reserved  procedure  MTPUT> 

(<matrix  append  parameter  part>) 

<matrix  append  parameter  parts:  = 

cmatrix  retrieval  parameter  part> 

<matrix  modify  statements:  = 

<reserved  procedure  MTM0D> 

(cmatrix  modify  parameter  part>) 
cmatrix  modify  parameter  parts:  = 

cmatrix  retrieval  parameter  part> 
cmatrix  delete  statements:  = 

creserved  procedure  MTDEL> 

(cmatrix  delete  parameter  part>) 
cmatrix  delete  parameter  parts:  = 


cdatabase  name> 


<matrix  identi fication> 
crow  number> ,[<col umn  number>], 
jccolumn  number> ,[<row  number>], 
|<empty> ,<empty> , 
cmatrix  manipulation  error  code> 
cmatrix  copy  statement>::  = 

creserved  procedure  MTC0PY> 
(cmatrix  copy  parameter  part>) 
cmatrix  copy  parameter  part>::  = 
cdatabase  name-copy  f rom> , 
cmatrix  identification-copy  from>, 
cdatabase  name-copy  to> , 
cmatrix  identification-copy  to>, 
cmatrix  manipulation  error  code> 


cmatrix  identification-copy  from>::  =  cmatrix  identi fication> 
cmatrix  identification-copy  to> : :  =  cmatrix  identi fication> 
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